Вот скажем я програмю . А дальше ?

Здравствуйте, Аноним, Вы писали:

А>Вот скажем я програмю . А дальше?
Вы программите, вас это мало касается. Это касается вашего менеджера. Как он назначает задачи, как расставляет приоритеты, как корректирует оценки, как учитывает риски и т.д. и т.п.
Agile это группа методологий и просто подходов для разработки проектов с динамично меняющимся Т.З. Как оказалось таких проектов 99.9%. Поэтому подходы типа всё спланировали, специфицировали и продумали, а потом быстро накодили — не работают. Т.З. подверженно постоянным изменениям и Agile использует техники чтобы минимизировать издержки вызваные этими изменениями.

Здравствуйте, Аноним, Вы писали:

А>Вот скажем я програмю . А дальше ?

ну вроде как не мало чего там http://agilemanifesto.org/principles.html

Здравствуйте, Blazkowicz, Вы писали:

B>проектов с динамично меняющимся Т.З. Как оказалось таких проектов 99.9%.

Громко сказано, весьма громко...
В вашей фирме — может быть, и 99.9%. В среднем по планете — гораздо меньше.
Существует множество фирм, работающих по старой доброй схеме концепция-разработка-сдача, и по соотношению дохода на сотруднико-рыло легко переплевывающих весь суперкульный ультрамодерный agile-детсад.

Здравствуйте, Аноним931, Вы писали:

А>Громко сказано, весьма громко...
ОК

А>В вашей фирме — может быть, и 99.9%. В среднем по планете — гораздо меньше.
Примеры плз, где-то ещё успешно waterfall применяется?

А>Существует множество фирм, работающих по старой доброй схеме концепция-разработка-сдача,
Что за "концепция"? Пришел начальник в понедельник и заявил: "У нас новая концепция"?

А>и по соотношению дохода на сотруднико-рыло легко переплевывающих весь суперкульный ультрамодерный agile-детсад.

Здравствуйте, Blazkowicz, Вы писали:

B>Примеры плз, где-то ещё успешно waterfall применяется?

Применяются голова и опыт, а не waterfall или agile.
Повторяю — я лично (по работе) знаю множество фирм, работающих по старой доброй схеме концепция-разработка-сдача.
Ибо в этих фирмах есть именно две вышеупомянутые, необходимые для успеха вещи — голова и опыт. А вот в agile-scrum-яслях с этим зачастую проблемы.

B>Что за "концепция"? Пришел начальник в понедельник и заявил: "У нас новая концепция"?
Это происходит как раз в agile-хаосе

B>http://lurkmore.so/images/d/d2/Novodvor.jpeg

И все-таки переплевывают, и очень прилично
Ты можешь продолжать постить картинки, но презираемым тобою не-agile-фирмам от этого ни горячо, ни холодно.
Собака лает, караван идет

Здравствуйте, Аноним931, Вы писали:

А>Применяются голова и опыт, а не waterfall или agile.
Это и есть agile.

А>Повторяю — я лично (по работе) знаю множество фирм, работающих по старой доброй схеме концепция-разработка-сдача.
Отсутствие конкретной спецификации это и есть agile.

А>Ибо в этих фирмах есть именно две вышеупомянутые, необходимые для успеха вещи — голова и опыт. А вот в agile-scrum-яслях с этим зачастую проблемы.
У тебя не верное понимание о том что такое agile. Agile это не только scrum или, например, XP. Я в первом ответе уже сформулировал. Это группа методологий и подходов. То что вы у себя не используете scrum, ещё не значит что вы не работаете по принципам Agile. "концепция-разработка" это и есть отсутствие детелизированого Т.З. Т.е. не четкие и динамично меняющиеся требования.

B>>Что за "концепция"? Пришел начальник в понедельник и заявил: "У нас новая концепция"?
А>Это происходит как раз в agile-хаосе
Концепция — минимальное не четкое Т.З.
Разработка — прототипизирование и реализация
Сдача — адаптация к поменявшимся и новым возникшим требованиям
Это всё и есть Agile.

А>И все-таки переплевывают, и очень прилично
А>Ты можешь продолжать постить картинки, но презираемым тобою не-agile-фирмам от этого ни горячо, ни холодно.
А>Собака лает, караван идет
Чувство собственного превосходства прям зашкаливает?

Здравствуйте, Аноним931, Вы писали:

B>проектов с динамично меняющимся Т.З. Как оказалось таких проектов 99.9%.
А>Повторяю — я лично (по работе) знаю множество фирм, работающих по старой доброй схеме концепция-разработка-сдача.
Ты своеобразно интепретировал мои слова и споришь со своей собственной интерпретацией.
Я писал о том что в 99.9% невозможно детально описать и зафиксировать Т.З. Ты же почему-то приравнял это к тому что 99.9% фирм работает по agile методологиям. Как бы не одно и то же.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Аноним931, Вы писали:

B>>проектов с динамично меняющимся Т.З. Как оказалось таких проектов 99.9%.
А>>Повторяю — я лично (по работе) знаю множество фирм, работающих по старой доброй схеме концепция-разработка-сдача.
B>Ты своеобразно интепретировал мои слова и споришь со своей собственной интерпретацией.
B>Я писал о том что в 99.9% невозможно детально описать и зафиксировать Т.З. Ты же почему-то приравнял это к тому что 99.9% фирм работает по agile методологиям. Как бы не одно и то же.

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

Здравствуйте, jakor, Вы писали:

B>>>проектов с динамично меняющимся Т.З. Как оказалось таких проектов 99.9%.
А>>>Повторяю — я лично (по работе) знаю множество фирм, работающих по старой доброй схеме концепция-разработка-сдача.
B>>Ты своеобразно интепретировал мои слова и споришь со своей собственной интерпретацией.
B>>Я писал о том что в 99.9% невозможно детально описать и зафиксировать Т.З. Ты же почему-то приравнял это к тому что 99.9% фирм работает по agile методологиям. Как бы не одно и то же.

J>не надо общих слов и воды на постном масле. народ хочет конкретного примера.
А чего ты так скромно сразу от имени народа. О каком примере речь? О примере чего? Ты видел на какой пост отвечал?

On 11.07.2012 22:25, Аноним 409 wrote:

>
> Вот скажем я програмю . А дальше ?
>

Ты програмишь, а кто-то за это платит деньги.

Наиболее модный способ выкачивания бабла из заказчиков называется agile
— вы платИте, а мы чего-нибудь когда-нибудь сделаем. Мы будем проводить
постоянные митинги, приоритезировать задачи и делать короткие итерации.
Таким образом вы можете быть уверены в том, что самые приоритетные для
вас задачи будут сделаны и попадут в production в максимально короткие
сроки.
Обратная сторона медали — поскольку не выделяется время на архитектуру и
проектирование, при решении следующих задач скорее всего придётся
переписать часть системы заново. Но у нас же есть автоматические тесты и
рефакторинг, так что это теоретически не так рискованно? Мы просто
возьмём ещё денег у заказчика, ведь у нас не waterfall а чистый moneyfall.
Да и ещё важный момент — если вы работаете по agile, а получается хрень,
то у вас просто неправильный agile! Вам нужно нанять консультанта,
подвергнуть команду коучингу и стать сертифицированным скрам-мастером,
это недорого и я знаю где.

--
WBR,
Serge.

P.S. Я совсем не против agile, если что.

Здравствуйте, Аноним, Вы писали:

А>Вот скажем я програмю . А дальше ?

Тебе на дают замыкаться на своём участке кода. Тебя периодически (раз в 1-3 недели) перебрасывают на другой участок, а на твой приходит другой человек. Это заставляет общаться с другими разрабами (с тем, кто до тебя писал этот участок и с тем, кто пришёл после тебя дописывать твой). Когда задалбываются объяснять, начинают писать комментарии, доки и тесты. Вас периодически (раз в день) отрывают минут на 10 от кодинга и заставляют расказывать всем окружающим чем ты сегодня занимался, какие имеешь затруднения и как их предполагаешь решать, другие тебе дают советы, ты даёшь другим советы (напоминает собрание общества анонимных кого-то-там — один жалуется, остальные делают вид, что сочувствуют). Иногда замечаешь, что тебя заставляют переписывать уже работающий код, но тебе пофиг, потому что не ты его писал и ломать его совсем не жалко. Методология стимулирует писать тесты, но на момент завершения интерации (1-3 недели)все тесты должны проходить, потому ты фиксиш тесты, так, чтобы они проходили или сносишь их нафиг. Через несколько итераций тестов уже много, но благодаря эволюционному отбору они уже работают в любых условиях, даже на глюкавом железе. Потому нужны тестеры, со временем ты с ними подружишься (видимо это проявление стокгольмского синдрома). Тестеров тоже перекидывают с одного участка функционала на другой. Потому они знают всё приложение и претендуют на роль архитектора. Ты тоже знаешь всё приложение и думаешь, что знаешь как его сделать лучше, но к счастью дедлайн очередной операции уже близко и заглушает твой зуд "переписать всё правильно". А после дедлайна тебя бросят на другой кусок, в котором ты совсем ничего не понимаешь, хотя он кажется тебе смутно знакомым (на самом деле ты этот кусок и писал 5 итераций назад, но с тех пор он изменился до неузнаваемости). Пока разберёшься, пока реализуешь требуемый функционал подойдёт следующий дедлайн. При этом проект движется по направлению к сдаче. Одни винят в этом успешную методологию Agile, другие — тот факт, что менеджеры всё равно работают по водопадной модели и крупномасштабная архитектура была прописана с самого начала.

Если серьёзно, то на разных уровнях одного проекта вполне может работать и Agile, и водопад. Agile хорошо работает с часто меняющимися требованиями, но требует тесного общения внутри команды (каждый с каждым) и коротких итераций. Понятно, что в командах из более чем 100 человек это нереализуемо. Водопад наоборот — хорошо масштабируется с ростом размера команды и проекта, но сопротивляется изменению требований. Так что главное — гармония.

B>Вы программите, вас это мало касается. Это касается вашего менеджера. Как он назначает задачи, как расставляет приоритеты, как корректирует оценки, как учитывает риски и т.д. и т.п.

Это заблуждение или неверно поняты основы Agile-методов. Особенность (и важность) их — вовлечение всех, в т.ч. программистов, в процесс (путем коллективного обсуждения и оценки работ).

Здравствуйте, SkyDance, Вы писали:

SD>Это заблуждение или неверно поняты основы Agile-методов. Особенность (и важность) их — вовлечение всех, в т.ч. программистов, в процесс (путем коллективного обсуждения и оценки работ).
Заблуждение считать что scrum и agile это синонимы. scrum это одна из конкретных методологий. Это по ней все вовлечены в общее обсуждение и оценки. Agile подход намного шире и одним только scrum не ограничивается.

B>Заблуждение считать что scrum и agile это синонимы. scrum это одна из конкретных методологий. Это по ней все вовлечены в общее обсуждение и оценки. Agile подход намного шире и одним только scrum не ограничивается.

Вне всякого сомнения.
Однако ж, "Individuals and interactions over processes and tools", первое и наиважнейшее заявление из Agile Manifesto, как раз и подразумевают повышенную роль коммуникаций разработчиков с другими персонажами.
Я просто привел один из самых ярких примеров. А так, с точно тем же успехом можно и в водопадной модели спрашивать девелоперов про прогнозы выполнения.

Здравствуйте, hrensgory, Вы писали:

H>On 11.07.2012 22:25, Аноним 409 wrote:

H>P.S. Я совсем не против agile, если что.
Да ты всё правильно написал.

А>по соотношению дохода на сотруднико-рыло легко переплевывающих весь суперкульный ультрамодерный agile-детсад.

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

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

А>>Вот скажем я програмю . А дальше?
B>Вы программите, вас это мало касается. Это касается вашего менеджера. Как он назначает задачи, как расставляет приоритеты, как корректирует оценки, как учитывает риски и т.д. и т.п.
B>Agile это группа методологий и просто подходов для разработки проектов с динамично меняющимся Т.З. Как оказалось таких проектов 99.9%. Поэтому подходы типа всё спланировали, специфицировали и продумали, а потом быстро накодили — не работают. Т.З. подверженно постоянным изменениям и Agile использует техники чтобы минимизировать издержки вызваные этими изменениями.

Ты загнул про 99,9% Их гораздо меньше. Более серьезные проекты в основном делаются по фиксированному ТЗ хотя бы даже потому, что заказчик хочет знать сколько надо платить и когда он получит конкретный, заранее оговоренный товар, а не кота в мешке.

Здравствуйте, goondick, Вы писали:

G>Более серьезные проекты в основном делаются по фиксированному ТЗ хотя бы даже потому, что заказчик хочет знать сколько надо платить и когда он получит конкретный, заранее оговоренный товар, а не кота в мешке.
Угу, и такое ТЗ потом в течении всего времени разработки сопровождается Change Request-ами. Невозможно полноценно и достаточно детально проработать любой крупный проект. Когда проект разрабатывается по фиксированой спецификации, а все запросы посылаются лесом, то заказчик опять проигрывает, так как лишен гибкости в маневре в свете вскрывшихся обстоятельств.

Здравствуйте, Blazkowicz, Вы писали:

Устойчивость к изменяющемуся ТЗ — это, по-моему, лишь часть Agile. Там еще много всего, в том числе спорного.

А>Устойчивость к изменяющемуся ТЗ — это, по-моему, лишь часть Agile. Там еще много всего, в том числе спорного.

Agile на то и agile, что допускает вольности — не хотите "спорное", не пользуйтесь.

Здравствуйте, Аноним, Вы писали:

А>Устойчивость к изменяющемуся ТЗ — это, по-моему, лишь часть Agile.
Это одна из основных целей. Остальное — средства.

А>Там еще много всего, в том числе спорного.
Например?

Здравствуйте, Mazay, Вы писали:

M>Если серьёзно, то на разных уровнях одного проекта вполне может работать и Agile, и водопад. Agile хорошо работает с часто меняющимися требованиями, но требует тесного общения внутри команды (каждый с каждым) и коротких итераций. Понятно, что в командах из более чем 100 человек это нереализуемо. Водопад наоборот — хорошо масштабируется с ростом размера команды и проекта, но сопротивляется изменению требований. Так что главное — гармония.

На масштабе проекта, который будет делать команда из более чем 100 человек, прописать требования так, чтобы потом их не пришлось менять, попросту невозможно (и даже на проектах гораздо меньшего масштаба это невозможно). Но я не об этом, на самом деле. Мне непонятно, почему вопрос вообще стоит как "или православный Agile, или waterfall — третьего не дано"? Наличие фазы предварительного планирования и процесса формального управления конфигурацией никак не противоречит концепции итеративно-инкрементальной разработки. Тот же пресловутый RUP никто не назовет водопадным подходом, но и Agile подходом (если не считать адаптацию OpenUP) он тоже не является.

Собственно, даже оставаясь в рамках Agile-подхода, его можно адаптировать к большим и серьезным проектам. Почитайте, например, Скотта Эмблера про масштабирование Agile-подхода и про подход Accelerated Delivery Platform

Здравствуйте, Blazkowicz, Вы писали:

А>>Вот скажем я програмю . А дальше?
B>Вы программите, вас это мало касается.

Как это мало, когда по Agile разработчики должны участвовать в планировании, расставлять приоритеты и самостоятельно выбирать себе таски на скрамах?
Как раз в рамках Agile роль руководителя сводится к соблюдению процесса (уменьшается).

Здравствуйте, Nikе, Вы писали:

N>Как это мало, когда по Agile разработчики должны участвовать в планировании, расставлять приоритеты и самостоятельно выбирать себе таски на скрамах?
скрам и Agile это не одно и то же

N>Как раз в рамках Agile роль руководителя сводится к соблюдению процесса (уменьшается).
как раз руководитель выбирает процесс и следит за его соблюдением, поэтому понимание и организация процесса это первоочередная задача руководителя, а не разработчика, который "вот я програмлю, а дальше что?"

Здравствуйте, Blazkowicz, Вы писали:

N>>Как это мало, когда по Agile разработчики должны участвовать в планировании, расставлять приоритеты и самостоятельно выбирать себе таски на скрамах?
B>скрам и Agile это не одно и то же
Я проходил корпоративный курс Agile, в рамках которого Scrum был назван его частью. Общим случаем не интересовался, так что возможно ошибаюсь.

N>>Как раз в рамках Agile роль руководителя сводится к соблюдению процесса (уменьшается).
B>как раз руководитель выбирает процесс
В рамках всех наблюдаемых случаев процесс выбирает не собственно руководитель проекта, а консилиум с вышестоящим руководством, где решаются концептуальные вопросы.

B>и следит за его соблюдением, поэтому понимание и организация процесса это первоочередная задача руководителя
Я это же сказал.

B>а не разработчика, который "вот я програмлю, а дальше что?"
По моему, человек который так говорит не может считаться разработчиком, это ранняя юниорская позиция. Разработчик должен понимать, что генерация кода — не самая значительная часть его работы.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, goondick, Вы писали:

G>>Более серьезные проекты в основном делаются по фиксированному ТЗ хотя бы даже потому, что заказчик хочет знать сколько надо платить и когда он получит конкретный, заранее оговоренный товар, а не кота в мешке.
B>Угу, и такое ТЗ потом в течении всего времени разработки сопровождается Change Request-ами. Невозможно полноценно и достаточно детально проработать любой крупный проект. Когда проект разрабатывается по фиксированой спецификации, а все запросы посылаются лесом, то заказчик опять проигрывает, так как лишен гибкости в маневре в свете вскрывшихся обстоятельств.

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

Здравствуйте, goondick, Вы писали:

G>да, без чейнж-реквестов редко обходится, но это один-два максимум а не "в течение всего времени", и их легко подшить к бухгалтерии и к долгосрочному планированию. не надо драматизировать, так как это все равно лучше бардака который творится при агиле (при взгляде со стороны заказчика)
Бардак он в головах, а не в agile.

Хороший человек по имени Peter Viscarola, который является одним из лучших специалистов по ядру Windows за пределами MS, помнится, сильно ругал Agile.

Причина: эта методология приучает людей писать код наспех, без должного внимания, приводит к медленной сходимости числа багов к нулю, и в отраслях девелопмента с высокой (по человеко-часам исправления) ценой баги может просто убить проект. Что не раз и случалось.

Также есть такая легенда, что Agile применим либо для а) разовых проектов уровня "сдал и отвалил", когда главный показатель бизнеса компании — число закрытых проектов в единицу времени, а не качество и б) для пускания пыли в глаза инвесторам в американской стартап-культуре (Agile позволяет очень быстро написать прототип).

В случае б) провал может произойти потому, что, после получения инвестиции необходимо делать уже не прототип, а продукт, который зачастую просто нереально сделать в Agile — не сойдется качество.

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

MSS>Причина: эта методология приучает людей писать код наспех, без должного внимания, приводит к медленной сходимости числа багов к нулю, и в отраслях девелопмента с высокой (по человеко-часам исправления) ценой баги может просто убить проект. Что не раз и случалось.

Т.е. "нетлёнку" по Agile не сделаешь, так?

MSS>В случае б) провал может произойти потому, что, после получения инвестиции необходимо делать уже не прототип, а продукт, который зачастую просто нереально сделать в Agile — не сойдется качество.

Почему качество не сойдется? Если в Definition of Done указаны критерии качества, в чем проблема?

MSS>Для решения проблемы с качеством в Agile часто ее комбинируют с TDD, но это сильно повышает нагрузку в плане человекоресурсов и зачастую по этой причине просто нереально для стартапа.

Вы в одном сообщении себе противоречите. Если у стартапа нет ресурсов на качественную и хорошую "нетленку", то им как раз Agile и поможет _хоть что-то_ сделать. А "нетленка" так и останется неготовой для продакшна, стартап загнется.

Вообще, смотрите истории всех успешных компаний. Все и везде начинали с "говнокода" (С), который просто был раньше, чем у других. Такова природа современного предпринимательства.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Хороший человек по имени Peter Viscarola, который является одним из лучших специалистов по ядру Windows за пределами MS, помнится, сильно ругал Agile.

Agile — то, что доктор прописал для команд, у которых еще нету никакого опыта совместной работы.
Сразу же наводится хоть какой-то порядок и получается performance boost
С уже устоявшимися командами с поставленными процессами ситуация может быть совсем иной.
Может помочь, а может и все нафиг похерить. Наблюдал неоднократно.
Проблема Agile только в ортодоксальности последователей Agile.
Ярые стронники гибких процессов на деле оказываются упертыми и негибкими

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, goondick, Вы писали:

G>>да, без чейнж-реквестов редко обходится, но это один-два максимум а не "в течение всего времени", и их легко подшить к бухгалтерии и к долгосрочному планированию. не надо драматизировать, так как это все равно лучше бардака который творится при агиле (при взгляде со стороны заказчика)
B>Бардак он в головах, а не в agile.

Бардак в головах у 95% разработчиков. Для этого есть тим-лид, чтоб бардак упорядочивать. В агиле каждый сам себе "тим-лид" и это печально.

Здравствуйте, goondick, Вы писали:

G>В агиле каждый сам себе "тим-лид" и это печально.
Это ваша странная интерпретация agile. Ничего такого в манифесте нет. Возможно, как и многие в этой теме, вы имеете ввиду Scrum, который, действительно, не работает, когда для многих команд, по причине того что они не способы самоорганизоваться.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, goondick, Вы писали:

G>>В агиле каждый сам себе "тим-лид" и это печально.
B>Это ваша странная интерпретация agile. Ничего такого в манифесте нет. Возможно, как и многие в этой теме, вы имеете ввиду Scrum, который, действительно, не работает, когда для многих команд, по причине того что они не способы самоорганизоваться.
Как в манифесте такого нет? а это: "self-organization and motivation". Если двух "индусов" посадить по парам, они "саморганизуются"?

Здравствуйте, goondick, Вы писали:

G>Как в манифесте такого нет? а это: "self-organization and motivation". Если двух "индусов" посадить по парам, они "саморганизуются"?
Самоорганизация не обозначает отсутствие контроля возведенное в абсолют.

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

SD>Т.е. "нетлёнку" по Agile не сделаешь, так?
Если только вопреки, а не благодаря.

SD>Почему качество не сойдется? Если в Definition of Done указаны критерии качества, в чем проблема?
Потому что появляется куча отвлекающих сущностей и англоязычных терминов, прямо не влияющих на качество кода.

SD>Вы в одном сообщении себе противоречите. Если у стартапа нет ресурсов на качественную и хорошую "нетленку", то им как раз Agile и поможет _хоть что-то_ сделать. А "нетленка" так и останется неготовой для продакшна, стартап загнется.
Точно так же он загнется и при наличии регулярных митингов. Если есть энтузиазм и хороший идеолог, то аджаил не поможет и не помешает.

SD>Вообще, смотрите истории всех успешных компаний. Все и везде начинали с "говнокода" (С), который просто был раньше, чем у других. Такова природа современного предпринимательства.
Не все и не везде. Всегда есть некий процент "золотого кода" в куче г-на. В каждом успешном проекте.

B>Проблема Agile только в ортодоксальности последователей Agile.

IMHO здесь проблема не Agile, — конкретные ортодоксальные личности ровно так же ортодоксалили бы waterfall или что угодно еще. Кстати, Agile это упоминает — мол, люди и их коммуникации важнее процессов и инструментов

TСП>Если только вопреки, а не благодаря.

Откуда такая статистика?

SD>>Почему качество не сойдется? Если в Definition of Done указаны критерии качества, в чем проблема?
TСП>Потому что появляется куча отвлекающих сущностей и англоязычных терминов, прямо не влияющих на качество кода.

Поясните, пожалуйста. Не нравится английский термин, используйте русский "что значит сделано". Это прямой и непосредственный способ проверки качества. Пока не проходят тесты, фича не сделана. Если у вас есть критерий качества — внесите его в определение "сделано" и у вас будет заданный уровень качества.

TСП>Точно так же он загнется и при наличии регулярных митингов. Если есть энтузиазм и хороший идеолог, то аджаил не поможет и не помешает.

Ваше мнение понятно. Допускаю, что у вас был негативный опыт применения чего-то из Agile. Это не значит, что у всех остальных опыт будет негативным. Кроме того, не всем же "нетленку" писать, у большинства проекты как раз "быстрее сделать и забыть".

TСП>Не все и не везде. Всегда есть некий процент "золотого кода" в куче г-на. В каждом успешном проекте.

А вот это, действительно, никакого отношения к Agile не имеет, и может существовать что в Agile-процессе, что вне его.

Здравствуйте, SkyDance, Вы писали:

B>>Проблема Agile только в ортодоксальности последователей Agile.

SD>IMHO здесь проблема не Agile, — конкретные ортодоксальные личности ровно так же ортодоксалили бы waterfall или что угодно еще. Кстати, Agile это упоминает — мол, люди и их коммуникации важнее процессов и инструментов

Это так. Но любая идея собирает вокруг себя людей определенного типа.
Ортодоксальность многих последователей Agile — это следствие методов,
с помощью которых Agile продвигается в "массы".
Ты был на официальных курсах по тому же SCRUM?
Тот еще brainwashing...

B>Это так. Но любая идея собирает вокруг себя людей определенного типа.
B>Ортодоксальность многих последователей Agile — это следствие методов,
B>с помощью которых Agile продвигается в "массы".

Не совсем понимаю, что имеется в виду. Агрессивного продвижения Agile в стиле "Гербалайф" я не видел (хотя, опять же, допускаю существование подобного).

Мне попадались куда более ортодоксальные сторонники "жесткого итеративного процесса" с любым чихом, проходящим через 10 инстанций и минимум 4 спецификации (бизнес, системная, архитектурная, тест-спецификация).

B>Ты был на официальных курсах по тому же SCRUM?
B>Тот еще brainwashing...

Был. Давно, правда, году так в 2008... никакого полоскания мозгов не было, строго по делу. Возможно, сейчас к этому делу присосалось слишком много теоретиков.

Здравствуйте, Аноним, Вы писали:

А>Вот скажем я програмю . А дальше ?

это придумали всякие консультанты, которые, якобы знают как нам надо работать ))
Аджайл движется в сторону итеративной разработки, это вроде и не так ново. И в сторону того, что не все требования известны заранее.
Тот кто пишет код без дизайна и архитектуры — пропадет. Дизайн присутствует практически в каждой задаче. Т.к. за редким исключением переписывается чисто приватная реализация чего-либо. наиболее часто меняются связи между компонентами, что-то расширяется, что-то убивается. Без понимания единой линии дизайна кода это будет "борода" из говнокода.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, goondick, Вы писали:

G>>Как в манифесте такого нет? а это: "self-organization and motivation". Если двух "индусов" посадить по парам, они "саморганизуются"?
B>Самоорганизация не обозначает отсутствие контроля возведенное в абсолют.

никто не говорит о "возведенное в абсолют", но контроль намного меньше, чем в тимлид-кнут-пряник сценарии и последствия бардака самоорганизации имеют место.

G>никто не говорит о "возведенное в абсолют", но контроль намного меньше, чем в тимлид-кнут-пряник сценарии и последствия бардака самоорганизации имеют место.

Это очень скользкая тема, "больше" или "меньше" контроля.
Визуально контроля может и меньше (т.к. над разработчиками не стоит тимлид с бамбуковой палкой).
Но на практике, контроль куда более строгий: текущее состояние проекта известно в любой момент. В отличие от "традиционной" разработки, когда вроде бы "все готово, но вот здесь надо немножко доделать — немножко, это сколько? — ну, наверное, две недели (и так каждые 2 недели)".

Просто методы контроля другие. Как известно, мотивация бывает лишь одного вида — самомотивация, когда сотрудник решает "надо бы поработать", и работает. Руководству важно знать перспективы проекта: что и когда будет сделано. Именно эти проблемы решают некоторые вариации Agile-процессов, в т.ч. пресловутый SCRUM.

Здравствуйте, SkyDance, Вы писали:

G>>никто не говорит о "возведенное в абсолют", но контроль намного меньше, чем в тимлид-кнут-пряник сценарии и последствия бардака самоорганизации имеют место.

SD>Это очень скользкая тема, "больше" или "меньше" контроля.
SD>Визуально контроля может и меньше (т.к. над разработчиками не стоит тимлид с бамбуковой палкой).
SD>Но на практике, контроль куда более строгий: текущее состояние проекта известно в любой момент. В отличие от "традиционной" разработки, когда вроде бы "все готово, но вот здесь надо немножко доделать — немножко, это сколько? — ну, наверное, две недели (и так каждые 2 недели)".

Каким образом оно известно? Со слов разработчика на стенд-ап митинге?

SD>Просто методы контроля другие. Как известно, мотивация бывает лишь одного вида — самомотивация, когда сотрудник решает "надо бы поработать", и работает. Руководству важно знать перспективы проекта: что и когда будет сделано. Именно эти проблемы решают некоторые вариации Agile-процессов, в т.ч. пресловутый SCRUM.

Как эти проблемы решает скрам? Мой практический опыт показал вточности наоборот. В скраме проект делят на задачи и оценивают сроки сами разработчики. Что сренде-статистический разработчик может оценить, это классическая тема шуток по типу умножаем на 3, но т.к. тут нет тим-лида, никто ни на что не умножает. В итоге таски запиханные в спринты не выполняются вовремя и разработчики начинают кормить "на следущей неделе", "в следущем спринте" отмазками.
Мне кажется, намного логичнее дать оценить сроки выполнения проекта главному программисту, который знает, что:
"вот этот модуль А быстро сделает Петя примерно за столько и столько, он делал подобное на прошлом проекте, сложно, но он в теме, 3-4 недели"
"вот это будет делать Ваня, он новичек, пусть поковыряется 2-3 недель так как в теме не шарит, как раз модуль Х будет готов к тому времени для интеграции.."
"эту задачу будет делать Дима, ему хватит 3 недели, закончит раньше поможет Пете" итд. итп.
А в скраме: Ваня, ты что хочешь делать. Ваня я хочу делать модуль А, я с этой платформой никогда не работал, интересно попробовать. Сколько времени займет? Слюнявит палец, выставляет по ветру, 1 неделю., Петя опытный программист, берет себе оставшийся скучный таск для "юниоров", оценивает его в 2 недели, (пока Ваня курит новою платформу и кормит "следущими неделями"), делает не спеша прореживая форумами и одноклассниками — Это хорошая информация для начальства или нет? Кто делает ваш строгий контроль в данном случае? Скрам-мастер? Так он не в курсе о способностях конкретного разработчика, и даже если в курсе, тут только можно развести руками: чек выбрал новую для него тему, ну естественно надо курить документацию, ну естественно перенесем в следущий спринт.... Это хорошие методы контроля?

G>Каким образом оно известно? Со слов разработчика на стенд-ап митинге?

Зачем же так сложно.
Все в том же SCRUM — с результатов итерации — принятых user stories. Поскольку принимаются только те фичи, которые действительно *сделаны* (D of Done), состояние проекта прослеживается лучше, чем со слов менеджера проекта. которому тоже напели разные программисты и тестировщики.

G>Как эти проблемы решает скрам?

В точности так, как написано в книгах и рассказывают в курсах. Другое дело, что мало кто в состоянии сделать scrum by the book, все обязательно считают своим долгом внести свою нетлёнку в это дело, и непременнейшим образом получить scrumbut.

G>Мой практический опыт показал вточности наоборот. В скраме проект делят на задачи и оценивают сроки сами разработчики. Что сренде-статистический разработчик может оценить, это классическая тема шуток по типу умножаем на 3, но т.к. тут нет тим-лида, никто ни на что не умножает. В итоге таски запиханные в спринты не выполняются вовремя и разработчики начинают кормить "на следущей неделе", "в следущем спринте" отмазками.

Это не scrum, а, извините, полнейшая хренотень. Видимо, ваш личный опыт основывается на совершенно отсутствующем процессе. Собралась могучая кучка и сказала "а теперь у нас будет скрам". Но никто из этой кучки точно не представляет, что работает, почему работает и как. Впрочем, то, что вы написали дальше, очень ярко демонстрирует ваше полнейшее непонимание того, что такое scrum и как он работает.

G>Мне кажется, намного логичнее дать оценить сроки выполнения проекта главному программисту, который знает, что:
G>"вот этот модуль А быстро сделает Петя примерно за столько и столько, он делал подобное на прошлом проекте, сложно, но он в теме, 3-4 недели"
G>"вот это будет делать Ваня, он новичек, пусть поковыряется 2-3 недель так как в теме не шарит, как раз модуль Х будет готов к тому времени для интеграции.."
G>"эту задачу будет делать Дима, ему хватит 3 недели, закончит раньше поможет Пете" итд. итп.

Вам именно что кажется. Ваш главный программист — точно такой же человек. Он точно так же не обладает знанием деталей, и знанием, что у Васи на следующей неделе ожидается ребёнок, а Петя попадёт по этому поводу в трехдневный запой.

G>А в скраме: Ваня, ты что хочешь делать. Ваня я хочу делать модуль А, я с этой платформой никогда не работал, интересно попробовать. Сколько времени займет? Слюнявит палец, выставляет по ветру, 1 неделю.

Это совершенно точно не скрам. Основная проблема Agile (и scrum в т.ч.), что все читали книжки, но никто их не понял. Потому что правильная реализация того же скрам невероятно проста. И в этом подвох, все начинают додумывать что-то своё, вместо scrum by the book поначалу и meta-scrum в дальнейшем.

То, что вы описали — традиционный раздолбай-менеджмент. Потому что в скрам все делается иначе.

Собирается вся команда. Сначала спрашивают — "Вася, сколько часов в следующем спринте (2 недели длиной) ты ожидаешь проработать с пользой?" Вася честно отвечает — "36 часов, потому что 3 дня на следующей неделе я проведу с женой и новорожденным, 2 дня я потрачу на исправление того-то и того-то для другой команды, и 4 часа каждые 2 недели мы тратим на вход/выход из итерации".
Потом этот же вопрос задают Пете. Петя оценивает реальную трудоспособность в 52 часа (80 часов — это 2 недели спринта, минус 3 дня запоя, минус 4 часа митингов).
Итогом этого мероприятия становится общее число теоретических часов, которые есть у команды. Эту цифра, вообще говоря, начальство может повергнуть в шок (т.к. легко выясняется, что половина времени команды уходит на непродуктивную ерунду), и начальство может завопить "аа-а-а-а-а никого не пущу в отпуск и всем запрещаю помогать другим командам". В этот момент важно не дрогнуть духом и не прогнуться при виде красной морды и воплей. Важно просто зафиксировать эту самую реальную оценку возможностей команды. В конце концов, можно ее даже и не показывать начальству (хотя это нарушит прозрачность процесса и суть скрам потеряется).

Далее, у команды есть список фич будущего продукта — backlog. Все они представляют собой сценарии работы пользователя. И все они имеют оценку сложности, но не в бессмысленных "2 недели" или "3 дня", а в относительных величинах (story points, SP): самая простой и легко реализуемый сценарий имеет сложность 1, остальные сценарии оцениваются относительно. Причем оценки эти не "от фонаря", и имеют вполне определенный ряд градаций. Кто-то применяет 1-2-4-8-16-32, кто-то ряд Фибоначчи (1-2-3-5-8-13-21), это некритично. Важен лишь факт, что ряд этих оценок фиксирован и конечен. Если какому-то сценарию хочется дать оценку "больше самой большой", значит, сценарий ошибочен (неатомарен или просто кривой), надо его разбивать на части или просто от него отказываться.

Далее, команда смотрит свою историю предыдущих спринтов. В ней видно, что имея 240 командных часов на спринт, команда в среднем заканчивает сценариев на 18 story points. Но в этом спринте у команды всего 180 часов (из-за ребенка Васи и запоя Пети), что позволяет набрать сценариев не более чем на 14 SP.

Что получается?

Команда реалистично оценивает свои возможности (как в виде того самого фокус-фактора, отношения "идеальных" и реальных рабочих часов, так и в виде количества SP/hr — т.н. velocity). Начальство, имея backlog, в любой момент может прикинуть, сколько еще пилить до релиза. Также упрощаются традиционные менеджмент-задачи вроде "а что будет, если мы Юру добавим к этому проекту" или "а если мы Васю насовсем отдадим в ту команду".

G>Кто делает ваш строгий контроль в данном случае? Скрам-мастер? Так он не в курсе

Вы совсем не поняли ни скрам, ни Agile в целом. Ваш подход традиционен для постсоветского гражданина: "над каждым поставить надсмотрщика с плёткой". Проявление этого эффекта я наблюдаю уже много лет (нынче, правда, со стороны) — в виде политической и экономической системы стран бСССР. Но попробуйте понять: руководству в первую очередь важны ответы на вопросы "что и когда будет реально сделано". Традиционный подход с экспертными оценками не в состоянии учитывать достаточное количество факторов. Кроме того, он негибок и требует постоянного вовлечения эксперта в проект. И даже в таком случае эксперт будет ошибаться. Доказано годами практики.
Описанный мной подход не заставит команду работать быстрее или лучше. Но при неукоснительном его соблюдении даст полную и прозрачную картину.

Настолько полную и прозначну, что, увы, руководство может решить закрыть проект, поняв, сколько на самом деле этот проект будет стоить. Ситуация реальная — принимал в этом непосредственное участие. Самое забавное — какой урок из этого вынесли сотрудники: "скрам — плохо, потому что проект закрывают, если бы не скрам, еще могли бы много лет тянуть и в ус не дуть". Это я к тому, что failure to implement scrum может быть вызвано разными причинами, в том числе и нежеланием сотрудников выставлять грязное бельё проекта на всеобщее обозрение. Тут требуется очень большая сила воли со стороны руководства. И, само собой, трезвое отношение оного руководства к реальности. Настоящей реальности, а не той, что создается отчетами линейными менеджерами.

Здравствуйте, SkyDance, Вы писали:

Да, я написал немного упрощенно, но смысл не меняется. Бардак не у нас в непонимании скрама а в самом скраме при разношерстной комманде (а идеальных комманд с равными по силе программистами практически нигде не встретишь, клонировать людей еще не научились).

SD> общее число теоретических часов, которые есть у команды.
SD> не в бессмысленных "2 недели" или "3 дня", а в относительных величинах (story points, SP): самая простой и легко реализуемый сценарий имеет сложность 1, остальные сценарии оцениваются относительно. Причем оценки эти не "от фонаря", и имеют вполне определенный ряд градаций. Кто-то применяет 1-2-4-8-16-32, кто-то ряд Фибоначчи (1-2-3-5-8-13-21), это некритично.
SD>Далее, команда смотрит свою историю предыдущих спринтов. В ней видно, что имея 240 командных часов на спринт, команда в среднем заканчивает сценариев на 18 story points. Но в этом спринте у команды всего 180 часов (из-за ребенка Васи и запоя Пети), что позволяет набрать сценариев не более чем на 14 SP.

Поймите уже наконец, что меняя шило на мыло: реальную временную оценку на поинты делу не поможет, потому что это все та же сверическо-вакуумная оценка времени выполнения проекта. Если стори весит 4SP, то для одного программиста она будет занимать неделю а для другого 2 дня, и наоборот для другой задачи.

SD> Команда реалистично оценивает свои возможности
средняя продуктивность среднего программиста помноженная на среднее время реального участия людей в команде с учетом среднестатицтической вероятности ухода в запои или задержек из-за курения новой документации?
Тим-лид также точно расчитать возможности своей команды только не в поинтах а в часах и даже с учетом запоев Пети.

SD> Начальство, имея backlog, в любой момент может прикинуть, сколько еще пилить до релиза.
А как же: "Но в этом спринте у команды всего 180 часов (из-за ребенка Васи и запоя Пети)"? Что они прикинут, если все спринты разные по количеству времени даже если velocity постоянная (сферически в вакууме), хотя и это не факт, потому что стори оцененная на 8SP к середине проекта может поменяться на 16 из-за того что это "команда оценила свои возможности" при составлении бэклога в начале проекта полгода назад. и тд. итп.

G>Да, я написал немного упрощенно, но смысл не меняется.

Да, вы написали упрощенно, отчего смысл не то что не поменялся, а потерялся вовсе.

G>Бардак не у нас в непонимании скрама а в самом скраме при разношерстной комманде (а идеальных комманд с равными по силе программистами практически нигде не встретишь, клонировать людей еще не научились).

"Вы не поверите" (С), первые 8-9 итераций мы тоже все хотели свалить на "разношерстные команды", "разношерстных людей в команде" и т.п., а потом просто привыкли, прониклись, набрали статистику и собрались, наконец, с духом — стали честно заявлять планируемые часы работы. Это один из самых сложных моментов, мужественно признаться себе и начальству, что половина времени уходит впустую. Отмечу, что в будущем это признание привело к положительному эффекту — нам разрешили создать некое "входное тестирование". Поясню: мы пользовались платформой, создаваемой другой командой (которая, в теории, должна была учитывать наши интересы, но на практике — плевала на нас с высокой колокольни и делала что хотела). До осознания, сколько времени уходило на борьбу с этой "платформой", нас заставляли собирать все грабли каждого очередного изменения в "платформе". После демонстрации того, сколько на это уходит, нам разрешили создать входные тесты. Если тесты не проходят — мы не переходили на новую версию.

G>Поймите уже наконец, что меняя шило на мыло: реальную временную оценку на поинты делу не поможет, потому что это все та же сверическо-вакуумная оценка времени выполнения проекта. Если стори весит 4SP, то для одного программиста она будет занимать неделю а для другого 2 дня, и наоборот для другой задачи.

Вы в очередной раз демонстрируете непонимание как Agile, так и того, откуда и почему берутся оценки.
Давайте по пунктам.
1. "Реальную временную оценку" разработчик дать не может. Читайте Mythical Man-Month, там очень хорошо объяснено, почему. Вкратце: любой программист дает оценку "сколько часов/дней/месяцев делать". Делать именно эту конкретную задачу. Но у разработчика кроме этой задачи всегда есть другие — отчеты, баги, запои, разборки с тестированием. Даже если это опытный программист, который очень в теме и может точно сказать "вот ту штуку делать 3 дня" — это не значит, что через 3 дня "штука" будет готова. Кстати, это одна из любимых ловушек менеджеров: "Вася, сколько делать А? — 3 дня. — Вася, а Б? — 2 дня. — Окей, делай параллельно, через 4 дня жду что все будет готово".
2. Ключевой элемент SP — относительность оценки. Что дает автоматическую коррекцию времени выполнения задач исходя из доступного времени. Пример на пальцах: команда сделала оценки фич А (8 часов), Б (11 часов) и В (21 час). Начали делать Б — на нее ушло 19 часов. Хороший тимлид в этот момент попросит провести переоценку задач А и В. Обычный менеджер даже и не подумает это сделать, но будет ожидать, что на А все так же потребуется 8 часов, на В — 21. Теперь представьте, что сценарии оценивали бы в SP (например, по методу ряда Фибоначчи) — соответственно, 1 SP, 2SP, 3 SP. После завершения Б за все те же 19 часов даже плохонький тим-лид бы догадался, сколько времени потребуется на А и В. Трюк, казалось бы, дешевый — отвязать сложность фичи от времени. Но работает железно.
3. Теперь про сами оценки. Они берутся не с потолка (т.н. "экспертные оценки"), а являются согласованным компромиссом внутри команды. Сей процесс зовется нынче planning poker — все члены команды должны согласиться с оценкой сложности. Иными словами, если Вася считает, что это 4 SP, а Петя — что 8, с помощью всех остальных членов команды будет найден компромисс. Возможно, опытный программист Вася поймет, что был неправ и был слишком оптимистичен в оценке. Возможно и другое — Петя заручится поддержкой Васи, и согласится на 4 SP. В конце концов, взрослые же люди — договорятся как-нибудь. Может, договорятся, что Вася будет делать эту конкретную фичу (и Вася знает, что у него в этом спринте на это будет время). Мы, например, еще на входе в итерацию примерно раскидывали stories по людям с учётом того, кто сколько времени планирует на следующий спринт.

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

G>средняя продуктивность среднего программиста помноженная на среднее время реального участия людей в команде с учетом среднестатицтической вероятности ухода в запои или задержек из-за курения новой документации?

Нет. Исторически подтвержденная производительность команды в целом. В scrum зовется velocity. А также отношение полезно проведенного времени к полному рабочему времени (focus factor).

G>Тим-лид также точно расчитать возможности своей команды только не в поинтах а в часах и даже с учетом запоев Пети.

Выше уже объяснено, почему тим-лид это сделает с низкой точностью. Кстати, тим-лид в scrum не нужен, scrummaster — это несколько иная роль.

G>А как же: "Но в этом спринте у команды всего 180 часов (из-за ребенка Васи и запоя Пети)"? Что они прикинут, если все спринты разные по количеству времени даже если velocity постоянная (сферически в вакууме), хотя и это не факт, потому что стори оцененная на 8SP к середине проекта может поменяться на 16 из-за того что это "команда оценила свои возможности" при составлении бэклога в начале проекта полгода назад. и тд. итп.

Прежде чем спорить, вы бы лучше попробовали. В том и прелесть относительных оценок, при "реальной оценке командой своих возможностей" менять эту относительную оценку не придется. Поменяется только, так сказать, курс у.е. SP — т.е. то самое количество "реальных часов", которые отделяют от релиза.
Проблема отдаленного планирования (тот самый случай, когда через полгода от команды из 10 человек осталось двое) сами по себе не решаются scrum. Вместо этого руководству дается трезвая, прозрачная и понятная оценка "сколько еще пилить вот для этих и этих фич". Руководство принимает решение — расширить команду, убрать фичи, выпустить как есть с меньшим набором фич.

Вообще, IMHO, самая большая сложность во внедрении любых подобных процессов — набраться смелости и честно освещать состояние проекта. На моей памяти большинство менеджеров предпочитают держать эту информацию в самой строжайшей тайне, особенно если дела идут так себе. Не помню кто, но, кажется, кто-то из участников rsdn давал ссылки на занятный блок одного человека — про illusion management.

Здравствуйте, SkyDance, Вы писали:

SD>Прежде чем спорить, вы бы лучше попробовали. В том и прелесть относительных оценок, при "реальной оценке командой своих возможностей" менять эту относительную оценку не придется. Поменяется только, так сказать, курс у.е. SP — т.е. то самое количество "реальных часов", которые отделяют от релиза.

Кстати, очень хорошая метафора — большинству ПМов/тимлидов, воспитанных на "классическом" подходе к проектному менеджменту, очень сложно осознать, что соотношение человеко-часы/story-point не является константой, и вся суть философии непрерывного улучшения как раз и сводится к тому, чтобы это соотношение минимизировать.

Что еще более интересно, в мире "классического" подхода к эстимированию у стори-поинтов есть практически полный аналог для выражения сложности — функциональные точки (и иже с ними — use case points, feature points и т.п.). Другое дело, что чуть менее чем всегда подход "сначала оцениваем сложность, и только потом из нее выводим оценку стоимости" отбрасывается в пользу "дубовой" экспертной оценки непосредственно стоимости в человеко-часах.

Здравствуйте, SkyDance, Вы писали:

G>>Да, я написал немного упрощенно, но смысл не меняется.

SD>Да, вы написали упрощенно, отчего смысл не то что не поменялся, а потерялся вовсе.

G>>Бардак не у нас в непонимании скрама а в самом скраме при разношерстной комманде (а идеальных комманд с равными по силе программистами практически нигде не встретишь, клонировать людей еще не научились).

SD>"Вы не поверите" (С), первые 8-9 итераций мы тоже все хотели свалить на "разношерстные команды", "разношерстных людей в команде" и т.п., а потом просто привыкли, прониклись, набрали статистику и собрались, наконец, с духом — стали честно заявлять планируемые часы работы.

Тут я не понимаю вобще вашей проблемы. Часы работы могут быть меньше за счет вдруг возникших других внеочередных задач, тех.поддержки, разборок с тестировщиками итд. Частично это можно запланировать, но иногда это не получается. В этом случае дается какой-то фиксированный средний процент от раб.времени на такие вещи. О каком "набраться с духом", "честно заявлять" вы говорите? О том что ваш разработчик заявит, что он будет 15 часов в неделю тратить на фейсбук?! Отличный самоконтроль и мотивация.

G>>Поймите уже наконец, что меняя шило на мыло: реальную временную оценку на поинты делу не поможет, потому что это все та же сверическо-вакуумная оценка времени выполнения проекта. Если стори весит 4SP, то для одного программиста она будет занимать неделю а для другого 2 дня, и наоборот для другой задачи.

SD>Вы в очередной раз демонстрируете непонимание как Agile, так и того, откуда и почему берутся оценки.
SD>Давайте по пунктам.
SD>1. "Реальную временную оценку" разработчик дать не может. ...

Никто и не спорит. Может дать тим-лид. Он может оценить сложность задачи относительно опыта разработчика которому она будет поручена. Естественно тим-лид должен быть в теме и знать свою команду.

SD>2. Ключевой элемент SP — относительность оценки. Что дает автоматическую коррекцию времени выполнения задач исходя из доступного времени. Пример на пальцах: команда сделала оценки фич А (8 часов), Б (11 часов) и В (21 час). Начали делать Б — на нее ушло 19 часов. Хороший тимлид в этот момент попросит провести переоценку задач А и В.

Ну так о таком тимлиде и говорим. Так что пофиг если задачи оценивали числами фибоначчи или человеко-часами. Относительность оценки в скраме еще более усугубляется тем, что для одно задача потянет на 4СП, для другого (менее опытного) на 8СП. Так что это не работет как вы тут вкусно все написали.

SD>3. Теперь про сами оценки. Они берутся не с потолка (т.н. "экспертные оценки"), а являются согласованным компромиссом внутри команды. Сей процесс зовется нынче planning poker — все члены команды должны согласиться с оценкой сложности. Иными словами, если Вася считает, что это 4 SP, а Петя — что 8, с помощью всех остальных членов команды будет найден компромисс. Возможно, опытный программист Вася поймет, что был неправ и был слишком оптимистичен в оценке. Возможно и другое — Петя заручится поддержкой Васи, и согласится на 4 SP. В конце концов, взрослые же люди — договорятся как-нибудь. Может, договорятся, что Вася будет делать эту конкретную фичу (и Вася знает, что у него в этом спринте на это будет время). Мы, например, еще на входе в итерацию примерно раскидывали stories по людям с учётом того, кто сколько времени планирует на следующий спринт.

Вот эти оценочные собрания и есть самый забавный цирк и эпический фейл скрама.

SD>На эту тему, кстати, рекомендую хорошую книжку Agile Estimating and Planning. Не уверен, что она есть на русском языке, но, надеюсь, для менеджера-то не станет проблемой прочитать ее в английском варианте. Думаю, она снимет значительную часть вопросов и претензий.

G>>средняя продуктивность среднего программиста помноженная на среднее время реального участия людей в команде с учетом среднестатицтической вероятности ухода в запои или задержек из-за курения новой документации?

SD>Нет. Исторически подтвержденная производительность команды в целом. В scrum зовется velocity. А также отношение полезно проведенного времени к полному рабочему времени (focus factor).

G>>Тим-лид также точно расчитать возможности своей команды только не в поинтах а в часах и даже с учетом запоев Пети.

SD>Выше уже объяснено, почему тим-лид это сделает с низкой точностью.

нет, не обьяснено

SD>Кстати, тим-лид в scrum не нужен, scrummaster — это несколько иная роль.

Естественно не нужен. Был бы тимлид, небыло бы бардака с оценками и "самоконтролем", не было бы этого разговора.

SD>Прежде чем спорить, вы бы лучше попробовали. В том и прелесть относительных оценок, при "реальной оценке командой своих возможностей" менять эту относительную оценку не придется. Поменяется только, так сказать, курс у.е. SP — т.е. то самое количество "реальных часов", которые отделяют от релиза.

Смысл от этого не меняется. Без разницы как вы оцениваете сложность задачи: в часах или енотах, время окончания проекта не будет известно, количество ресурсов не будет толком оценено ни в начале ни в сердине проекта. Только ближе к завершению можно верить velocity и умножать ее на ваши числа фибоначи. Почему ваша красивая теория редко работает в реале: да потому что нет в скраме "реальной оценки командой своих возможностей". Будет средняя по больнице оценка которую можно в классике добится даже без тимлида, спросив каждого раработчика, найдя среднее и умножив на 3.


SD>Вообще, IMHO, самая большая сложность во внедрении любых подобных процессов — набраться смелости и честно освещать состояние проекта.

Согласен, и это не зависит от методологий.

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

Видите — вы снова не понимаете самых что ни на есть базовых вещей в SCRUM.
Внутри спринта не может возникнуть никаких незапланированных задач. Одна из обязанностей скраммастера — следить за этим. В традиционном менеджменте этому не уделяется достаточно внимания. Впрочем, традиционный менеджмент обычно менее ритмичен в плане итераций. Зачастую итераций вообще нет. А если есть, то недостаточно строгие и жесткие.

G>О том что ваш разработчик заявит, что он будет 15 часов в неделю тратить на фейсбук?! Отличный самоконтроль и мотивация.

Не беспокойтесь — такие заявления никто не воспринимает всерьез. Это не значит, что разработчик не тратит упомянутые 15 часов на фейсбук. Это значит, что velocity (именно velocity, а не focus factor) из-за этого снижается.

G>Никто и не спорит. Может дать тим-лид. Он может оценить сложность задачи относительно опыта разработчика которому она будет поручена. Естественно тим-лид должен быть в теме и знать свою команду.

Кажется, я начинаю понимать. Вы, вероятнее всего, никогда не занимались управлением. Даже на уровне тим-лида. Потому как если бы занимались, то точно бы понимали — тим-лид не может оценить, сколько времени требуется тому или иному разработчику на ту или иную задачу. В том числе и потому, что тим-лид может быть не в курсе относительно сложности этой задачи. Так или иначе, тим-лид будет опираться на экспертную сложность задачи. Иными словами, что ему Вася скажет, то тим-лид и запишет у себя в табличке, умножив на персональный коэффициент (вы на 3 умножите, кто-то на 2, кто-то на "персональный коэффициент разработчика", считающийся как соотношение оценок данного разработчика к реальным затратам времени).

Видите ли, planning poker — это не только инструмент для оценки сложности задачи. Но еще и метод согласования оной оценки. А также — мини-штурм задачи: один эксперт может банально не вспомнить все заморочки конкретной реализации, и ошибиться в прогнозах. В команде всегда есть пессимисты и оптимисты. Неспроста же при несовпадении оценок выбирают двух человек — тот, кто выдал самую высокую, и тот, кто выдал самую низкую — объясняют всей команде, почему они выбрали такую оценку, и затем проводится повторный покер.

Позвлю себе задать вопрос: вы хоть раз вообще проводили planning poker? Не в виде шутливого баловства, в которое никто не верит (ну так, поржать собрались), а — на полном серьезе? Проведите. Хотя бы десяток раз. Удивитесь эффективности этого инструмента. Само собой, не забывайте о time boxing — дабы, как это часто бывает, встреча не превратилась в треп на тему "как лучше сделать".

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

G>Ну так о таком тимлиде и говорим. Так что пофиг если задачи оценивали числами фибоначчи или человеко-часами. Относительность оценки в скраме еще более усугубляется тем, что для одно задача потянет на 4СП, для другого (менее опытного) на 8СП. Так что это не работет как вы тут вкусно все написали.

Попробуйте понять: в scrum оценки идут на команду. Не на человека. И они делаются относительно самой простой фичи. Понимаете? Что для опытного, что для неопытного — фича 2 SP вдвое сложнее, чем 1 SP. Вы никак не возьмете в толк, что SP не является аналогом или синонимом man-hour. В SP меряется сложность реализации фичи, а не то, сколько времени это займет у того или иного программиста.

В классическом scrum-by-the-book не выделяется персональная производительность члена команды. Все работают вместе. Вася мог сделать 8 SP в итерации, Петя — всего 4 (менее опытный, дольше разбирался). Вместе они сделали 12. На следующую итерацию, если в ней ожидается столько же рабочего времени, следует взять ровно те же 12 SP. С высокой долей вероятности Вася снова сделает 8, Петя — 4.

Теперь вы понимаете, почему так хороши относительные оценки?

G>Вот эти оценочные собрания и есть самый забавный цирк и эпический фейл скрама.

Это ваш единственный аргумент? Ну что же, если у вас даже такие простые вещи превращаются в цирк, вам даже пытаться не стоит самостоятельно организовать процесс. Привлекайте специалистов. Могу порекомендовать одного немца.
Или продолжайте работать как работаете. В конце концов, это же вы хотите попробовать Agile.

G>Естественно не нужен. Был бы тимлид, небыло бы бардака с оценками и "самоконтролем", не было бы этого разговора.


Улыбнуло. Выходит, когда тим-лид есть, никакого бардака с оценками нет. Еще, поди, и проекты в срок завершаются. Со всеми фичами и без багов.

G>Смысл от этого не меняется. Без разницы как вы оцениваете сложность задачи: в часах или енотах, время окончания проекта не будет известно, количество ресурсов не будет толком оценено ни в начале ни в сердине проекта. Только ближе к завершению можно верить velocity и умножать ее на ваши числа фибоначи.

Практика показывает, что достаточно 8-10 итераций для команды, никогда не пробовавшей scrum. И буквально 3-5 для тех, кто уже работал по scrum, но не в этой конкретной команде.

G>Почему ваша красивая теория редко работает в реале: да потому что нет в скраме "реальной оценки командой своих возможностей". Будет средняя по больнице оценка которую можно в классике добится даже без тимлида, спросив каждого раработчика, найдя среднее и умножив на 3.

Это не теория, это практика — по закрытию проекта по истечении 14 (или 18? склероз-с, не помню-с) итераций. Как раз тогда, когда стало понятно — "не потянем". Ибо с тем бюджетом, velocity и обязательным набором фич до релиза было еще 14-17.

А вы демонстрируете классическую ошибку начинающего — "опрошу всех, возьму среднее и умножу на N". Этот метод не работает. Потому что в таком варианте (подходите по очереди к каждому разработчику) разработчики не контактируют между собой и не могут объяснить, почему эту фичу делать сложно (или, напротив, легко). Если дать им возможность это сделать — оценки будут более взвешенными.

Повторю свою рекомендацию — Agile Estimating and Planning. Отличная книга. Даже для тех, кто заведомо похоронил для себя Agile.

Здравствуйте, SkyDance, Вы писали:

SD>Это не теория, это практика — по закрытию проекта по истечении 14 (или 18? склероз-с, не помню-с) итераций. Как раз тогда, когда стало понятно — "не потянем". Ибо с тем бюджетом, velocity и обязательным набором фич до релиза было еще 14-17.

Вот тут у меня возникает логичный вопрос: а кто в этом случае "оплачивает банкет"? Если считать, что итерация — две недели, это где-то полгода работы. Т.е. проект закрыт — только после полугода работы стало ясно: "не потянем". Однако, на протяжении этого полугода N разработчиков как минимум получали зарплату. За чей счет банкет?
И, кстати, как отнесся заказчик к тому факту, что потерял полгода времени — и получил (около)нулевой выхлоп в результате?

Или я не прав? Проясни эти моменты, плз.

Ну да, лучше бы конечно было как в обычном менеджменте. Т.е. узнали бы что проект не потянем через год когда его надо сдавать?

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

А вообще SkyDance все очень правильно пишет. У меня был очень положительный опыт работы на скраме. Если понимать зачем все это делается и делать реально, а не эмулировать скрам (т.е. собираться один раз в день на daily scrum и все) — то эффект очень положительный.

Другое дело, что это надо чтобы и руководство это понимало и двигало скрам. Т.е. чтобы ему было выгодно реально софт делать, а не просто квадратики рисовать в microsoft project...

Опять же скрам очень себя плохо показал на распределенной и интернациональной команде. Просто в силу разницы во времени и национальных особенностей не сложилась команда.

Так что по мне, дак скрам очень хорош для небольштх команд когда они сидят в одном месте и реально хотят что-то сделать и имеют поддержку руководства. Во всех остальных случаях — не работает...

Вячеслав Педак

Здравствуйте, Vlad_SP, Вы писали:

V_S>Вот тут у меня возникает логичный вопрос: а кто в этом случае "оплачивает банкет"? Если считать, что итерация — две недели, это где-то полгода работы. Т.е. проект закрыт — только после полугода работы стало ясно: "не потянем". Однако, на протяжении этого полугода N разработчиков как минимум получали зарплату. За чей счет банкет?
V_S>И, кстати, как отнесся заказчик к тому факту, что потерял полгода времени — и получил (около)нулевой выхлоп в результате?

V_S>Или я не прав? Проясни эти моменты, плз.

Здравствуйте, SkyDance, Вы писали:


SD>Внутри спринта не может возникнуть никаких незапланированных задач. Одна из обязанностей скраммастера — следить за этим.

Да запросто. Поддержка старых версий (помощь тех.саппорту по внезапно возникшим вопросам по старым версиям), поддержка QА отдела (помощь по внезапно возникшим вопросам по текущему проекту). Если с QА можно запланировать обьем времени, то с саппортом это не выйдет.
Так я и не понял, откуда у вас такое понятие, что разработчик должен "переступить через свой стыд и признатся" сколько времени он потратит на следущий спринт?

SD>В традиционном менеджменте этому не уделяется достаточно внимания.

Вы в этом уверенны? Это аксиома традиционного менеджмента? У вас был печальный личный опыт?


SD>Не беспокойтесь — такие заявления никто не воспринимает всерьез. Это не значит, что разработчик не тратит упомянутые 15 часов на фейсбук. Это значит, что velocity (именно velocity, а не focus factor) из-за этого снижается.

Вот тут кстати интересно насчет самоконтроля. Поигрался народ в покер, начали спринт, потратили 15 часов на фейсбук, после замерили велосити. Новый спринт, опять фейсбук, велосити таже. В относительных числах фибоначчи все выглядит гладко. Не у кого звоночек не зазвонит.

SD>Кажется, я начинаю понимать. Вы, вероятнее всего, никогда не занимались управлением.

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

SD>Потому как если бы занимались, то точно бы понимали — тим-лид не может оценить, сколько времени требуется тому или иному разработчику на ту или иную задачу.

Сколько потребуется с учетом фейсбуков — нет конечно. Но запросто может достаточно точно оценить за какое время именно данный разработчик с конкретной компетенцией ее может сделать.

SD>В том числе и потому, что тим-лид может быть не в курсе относительно сложности этой задачи. Так или иначе, тим-лид будет опираться на экспертную сложность задачи.

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

SD>Видите ли, planning poker — это не только инструмент для оценки сложности задачи. Но еще и метод согласования оной оценки.

Ну при классической разработке тимлиды с PM и CTO не закрываются в черной комнате для решения кому сколько и к какому сроку надо что сделать. Есть свои методы согласования в команде как во время планирования так и во время реализации. Собрания, летучки, брейн-штормы никто не отменял.


SD>Позвлю себе задать вопрос: вы хоть раз вообще проводили planning poker? Не в виде шутливого баловства, в которое никто не верит (ну так, поржать собрались), а — на полном серьезе? Проведите. Хотя бы десяток раз. Удивитесь эффективности этого инструмента. Само собой, не забывайте о time boxing — дабы, как это часто бывает, встреча не превратилась в треп на тему "как лучше сделать".

Участвовал и проводил.

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

Привлекали специалистов, платили, кстати им кучу баблосов. Итог не порадовал. Скорость разработки и качество то же.

SD>Попробуйте понять: в scrum оценки идут на команду. Не на человека. И они делаются относительно самой простой фичи. Понимаете? Что для опытного, что для неопытного — фича 2 SP вдвое сложнее, чем 1 SP. Вы никак не возьмете в толк, что SP не является аналогом или синонимом man-hour. В SP меряется сложность реализации фичи, а не то, сколько времени это займет у того или иного программиста.

SD>В классическом scrum-by-the-book не выделяется персональная производительность члена команды.

Это и плохо. Очень плохо.

SD>Теперь вы понимаете, почему так хороши относительные оценки?

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


SD>Выходит, когда тим-лид есть, никакого бардака с оценками нет. Еще, поди, и проекты в срок завершаются. Со всеми фичами и без багов.

Вы наверное удивитесь, но проект с грамотным тимлидом при классике завершается в худшем случае за такое же время с теми же фичами и с таким же кол-вом багов как и при скраме под чутким руководством самого супер-пупер скрам специалиста.

G>>Смысл от этого не меняется. Без разницы как вы оцениваете сложность задачи: в часах или енотах, время окончания проекта не будет известно, количество ресурсов не будет толком оценено ни в начале ни в сердине проекта. Только ближе к завершению можно верить velocity и умножать ее на ваши числа фибоначи.

SD>Практика показывает, что достаточно 8-10 итераций для команды, никогда не пробовавшей scrum. И буквально 3-5 для тех, кто уже работал по scrum, но не в этой конкретной команде.

G>>Почему ваша красивая теория редко работает в реале: да потому что нет в скраме "реальной оценки командой своих возможностей". Будет средняя по больнице оценка которую можно в классике добится даже без тимлида, спросив каждого раработчика, найдя среднее и умножив на 3.

SD>Это не теория, это практика — по закрытию проекта по истечении 14 (или 18? склероз-с, не помню-с) итераций. Как раз тогда, когда стало понятно — "не потянем". Ибо с тем бюджетом, velocity и обязательным набором фич до релиза было еще 14-17.

И что произошло потом? Вы попросили у заказчика еще столько же денег или обьявили себя банкротом? В этом вся "прелесть" скрама. Узнать "потянем-не потянем" в середине распила.

SD>А вы демонстрируете классическую ошибку начинающего — "опрошу всех, возьму среднее и умножу на N". Этот метод не работает. Потому что в таком варианте (подходите по очереди к каждому разработчику) разработчики не контактируют между собой и не могут объяснить, почему эту фичу делать сложно (или, напротив, легко). Если дать им возможность это сделать — оценки будут более взвешенными.

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


Я вообще не сказал, что скрам плох. Есть в нем положительные моменты, но бардака там полно, как бы вы тут его медом не мазали.

Здравствуйте, vpedak, Вы писали:

V>Ну да, лучше бы конечно было как в обычном менеджменте. Т.е. узнали бы что проект не потянем через год когда его надо сдавать?

Если проект не замерять в "енотах", как это делается в скраме, а в реальных "человеко-часах" разбирающимся в теме людям, то узнали бы еще на стадии планирования.


V>А вообще SkyDance все очень правильно пишет. У меня был очень положительный опыт работы на скраме. Если понимать зачем все это делается и делать реально, а не эмулировать скрам (т.е. собираться один раз в день на daily scrum и все) — то эффект очень положительный.

V>Другое дело, что это надо чтобы и руководство это понимало и двигало скрам. Т.е. чтобы ему было выгодно реально софт делать, а не просто квадратики рисовать в microsoft project...

V>Опять же скрам очень себя плохо показал на распределенной и интернациональной команде. Просто в силу разницы во времени и национальных особенностей не сложилась команда.

V>Так что по мне, дак скрам очень хорош для небольштх команд когда они сидят в одном месте и реально хотят что-то сделать и имеют поддержку руководства. Во всех остальных случаях — не работает...

Скрам реально работает, если... если выполнить очень грамотно очень много "если". И результат в итоге будет такой же, как от классической методологии, где "если" тоже нужны но их надо гораздо меньше.

Здравствуйте, goondick, Вы писали:

V>>Так что по мне, дак скрам очень хорош для небольштх команд когда они сидят в одном месте и реально хотят что-то сделать и имеют поддержку руководства. Во всех остальных случаях — не работает...
G>Скрам реально работает, если... если выполнить очень грамотно очень много "если". И результат в итоге будет такой же, как от классической методологии, где "если" тоже нужны но их надо гораздо меньше.

Господа, мне кажется, вы спорите о полезности Скрама в контексте проекта с более-менее стабильными требованиями, который можно оценить и запланировать заранее. И именно в таком контексте Скрам действительно может проигрывать другим инкрементально-итеративным методологием с бОльшим уклоном в предварительное планирование, нежели адаптацию.

И здесь стоит вспомнить о том ( да-да, капитанствую ), что Скрам задумывался несколько для других условий, а именно — когда динамика изменения требований очень высока и строить какие-либо долгосрочные планы просто не имеет смысла. Как в таких условиях могут работать более традиционные методологии, основывающиеся на тщательном планировании — я не очень себе представляю.

Здравствуйте, diez_p, Вы писали:

_>Тот кто пишет код без дизайна и архитектуры — пропадет. Дизайн присутствует практически в каждой задаче. Т.к. за редким исключением переписывается чисто приватная реализация чего-либо. наиболее часто меняются связи между компонентами, что-то расширяется, что-то убивается. Без понимания единой линии дизайна кода это будет "борода" из говнокода.

Знаете, это как в старом анекдоте про "celibate" и "celebrate", ну, или, если хотите, другом старом анекдоте про "Рабинович напел"

Во-первых, насколько я помню, только одна из Agile-методологий, а именно — Extreme Programming, призывает не проектировать архитектуру системы заранее, но даже в XP есть понятия архитектурного прототипирования и, по сути, описывающей основные концепции дизайна метафоры системы. К тому же, XP обязательно требует наличия практики test-driven development, а это и есть методика дизайна кода, только альтернативная традиционному рисованию UML-диаграмм.

Во-вторых, в контексте динамично меняющихся требований (а именно в нем применение Agile-методологий наиболее выигрышно) действительно нет смысла пытаться продумать заранее всю архитектуру и дизайн целиком и полностью. Как правило, достаточно определиться со "скелетом", "основными несущими конструкциями", а остальной дизайн наращивать на этот скелет уже итеративно.

Здравствуйте, goondick, Вы писали:

G>Если проект не замерять в "енотах", как это делается в скраме, а в реальных "человеко-часах" разбирающимся в теме людям, то узнали бы еще на стадии планирования.

очень смешно... Вы хоть один проект пытались так оценить? И у вас получилось?
То-то большинство проектов как "вываливась" из сроков и бюджета и до скрама и после и продолжают вываливаться.
Мы блин тут пытаемся реально оценить разработку в 3 недели сроком (один спринт) и то не очень попадаем (ну хоть не на 100% промахиваемся), а тут за год оценить надо...


Вячеслав Педак

Здравствуйте, vpedak, Вы писали:

V>То-то большинство проектов как "вываливась" из сроков и бюджета и до скрама и после и продолжают вываливаться.

Хорошо. Ты можешь еще до начала проекта по скраму/эджайлу/etc. четко сказать Заказчику — когда проект будет закончен и сколько денег на это потребуется?

(А ведь именно это интересует Заказчика больше всего, а не применяемые методологии....)

Здравствуйте, vpedak, Вы писали:

V>Здравствуйте, goondick, Вы писали:

G>>Если проект не замерять в "енотах", как это делается в скраме, а в реальных "человеко-часах" разбирающимся в теме людям, то узнали бы еще на стадии планирования.

V>очень смешно... Вы хоть один проект пытались так оценить? И у вас получилось?

По разному бывало... Со стажем и со знанием команды получается более точно, это факт.

V>То-то большинство проектов как "вываливась" из сроков и бюджета и до скрама и после и продолжают вываливаться.

Человеческий фактор.

V>Мы блин тут пытаемся реально оценить разработку в 3 недели сроком (один спринт) и то не очень попадаем (ну хоть не на 100% промахиваемся), а тут за год оценить надо...

Делайте ударение на "оценить надо". Называйте это издержки производства или как-то еще, но заказчик без этого с вами работать вряд-ли будет.

А то, что вы промахиваетесь даже в стринте, так это уже обсуждалось выше: средне-арифметической оценкой пессимистов и оптимистов точный ответ не узнаешь. Тем более если он дается в енотах в стори поинтах. Неопытный молодой программист не сможет хорошо оценивать обьем задачи, будь он оптимистом или пессимистом. При покер-шоу несколько таких "оценщиков" и вносят интересные коррективы, что грех не ошибиться даже в краткосрочном планировании.

Здравствуйте, DmytroL, Вы писали:


DL>Господа, мне кажется, вы спорите о полезности Скрама в контексте проекта с более-менее стабильными требованиями, который можно оценить и запланировать заранее. И именно в таком контексте Скрам действительно может проигрывать другим инкрементально-итеративным методологием с бОльшим уклоном в предварительное планирование, нежели адаптацию.

Да в принципе это понятно, просто вся эта ветка шла про "самоконтроль" бойцов скрама vs. бардак, а потом разговор скатился как всегда до общих недостатков и преимуществ.

DL>И здесь стоит вспомнить о том ( да-да, капитанствую ), что Скрам задумывался несколько для других условий, а именно — когда динамика изменения требований очень высока и строить какие-либо долгосрочные планы просто не имеет смысла. Как в таких условиях могут работать более традиционные методологии, основывающиеся на тщательном планировании — я не очень себе представляю.

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

Здравствуйте, goondick, Вы писали:

G>Никто, не спорит, задумывался для этого и соответсвенно кое-где успешно работает (где не считают деньги и сроки, стартапы с богатыми инвесторами? гугл?).

Мне кажется, вы полагаете третью переменную, объем функционала (scope), всегда жестко зафиксированной. В то же время, Скрам прекрасно работает в условиях ограниченного бюджета и сроков при условии, что реализованный функционал остается степенью свободы и грамотно приоритезирован. А вот в сценарии fixed-all Скрам, действительно, не работает.

К тому же, стоит вспомнить тот факт, что в Скраме в конце каждой итерации получается полностью работоспособная версия продукта (в менее ортодоксальной трактовке — версия, требующая минимальной стабилизации). Если это условие не соблюдается, то это уже не Скрам, а простите, СкрамНо Из чего следует, что бюджет и сроки контролируются с гранулярностью стоимости и продолжительности итерации, и после любой итерации заказчик может сказать "стоп!" и не остаться у разбитого корыта, как это бывает при традиционном подходе, а получить версию, где реализованы и работоспособны наиболее критичные бизнес-функции.

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

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

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

Здравствуйте, DmytroL, Вы писали:

тут, вишь ты, вот в чем фокус....

В этой ветке коллега vpedak привел аргумент в пользу эджайла/скрама/etc.:

V>То-то большинство проектов как "вываливась" из сроков и бюджета и до скрама и после и продолжают вываливаться.

Так вот, уверяю тебя: если в "традиционном" менеджменте реализованный функционал также оставить на усмотрение менеджера проекта — с определенной (и достаточно большой) степенью свободы и грамотно расставленными приоритетами фич, — то и "традиционно" управляемые проекты вдруг перестанут вываливаться из сроков и бюджета.

Здравствуйте, goondick, Вы писали:

V>>То-то большинство проектов как "вываливась" из сроков и бюджета и до скрама и после и продолжают вываливаться.

G>Человеческий фактор.

Ну да, именно его и предлагает учитывать agile (и еще то, что требования будут изменяться). Поэтому и получается лучше, чем просто квадратики рисовать в MS Project


G>Делайте ударение на "оценить надо". Называйте это издержки производства или как-то еще, но заказчик без этого с вами работать вряд-ли будет.

дак а где я писал что оценивать не надо? Fixed price проекты они и на agile могут делаться. Понятно, что когда проект подписывают то оговаривают что вот что-то надо сделать за какое-то время и за столько-то денег.

Только это описание проекта оно высокоуровневое. Разница в том какие именно и как фичи делать и с каким качеством. Это может в несколько раз менять размер реальной работы.

G>А то, что вы промахиваетесь даже в стринте, так это уже обсуждалось выше: средне-арифметической оценкой пессимистов и оптимистов точный ответ не узнаешь. Тем более если он дается в енотах в стори поинтах. Неопытный молодой программист не сможет хорошо оценивать обьем задачи, будь он оптимистом или пессимистом. При покер-шоу несколько таких "оценщиков" и вносят интересные коррективы, что грех не ошибиться даже в краткосрочном планировании.

ну да, конечно если команда которая реально это делает не может точно оценить, то какой-то "опытный" менеджер конечно лучше оценит... Все что он обычно и делает это закладывает дополнительное время на всякие риски (ему же по башке дадут если вовремя не успеет). Поэтому чем меньше запланируешь и чем больше заложишь на всякий-случай — тем ты более защищен.

В agile же все проще. Идет оценка производительности команды и на основании ее делается оценка когда проект будет закончен. Но это работает только тогда когда и заказчик и исполнитель заинтересованы в результате. А не просто заинтересованы в том, чтобы какую-то хрень сдали вовремя (неважно насколько она получилась хороша и полезна).

Ну а так как в большинстве случаев всем пофиг на реальный результат — то и agile редко где реально нужен получается. Потому что он реальность показывает и надо принимать решения за которые приходится ответ держать... А кто же такое любит?


Вячеслав Педак

Здравствуйте, SkyDance, Вы писали:

SD>3. Теперь про сами оценки. Они берутся не с потолка (т.н. "экспертные оценки"), а являются согласованным компромиссом внутри команды. Сей процесс зовется нынче planning poker — все члены команды должны согласиться с оценкой сложности. Иными словами, если Вася считает, что это 4 SP, а Петя — что 8, с помощью всех остальных членов команды будет найден компромисс. Возможно, опытный программист Вася поймет, что был неправ и был слишком оптимистичен в оценке. Возможно и другое — Петя заручится поддержкой Васи, и согласится на 4 SP. В конце концов, взрослые же люди — договорятся как-нибудь. Может, договорятся, что Вася будет делать эту конкретную фичу (и Вася знает, что у него в этом спринте на это будет время). Мы, например, еще на входе в итерацию примерно раскидывали stories по людям с учётом того, кто сколько времени планирует на следующий спринт.

Проблема planning poker в том, что он таки дает оценку с потолка, хоть и согласованную между членами команды. Это происходит из-за того, что во время оценки члены команды зачастую не знают как именно они будут эту фичу реализовывать, надеясь сориентироваться в процессе её выполнения. У них просто нет времени и возможности хорошо подумать и покопаться в исходниках. В результате получается, что в процессе выполнения итерации вдруг неожиданно выясняется, что для реализации фичи потребуется масштабный рефакторинг и данные во время покера потолочные оценки совершенно неадекватны.

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

Я являюсь одним из самых опытных разработчиков на проекте, практически не осталось такого модуля, к которому бы я не приложил руку. Разрабатываемый коробочный продукт уже пережил несколько релизов, Critical Fix'ов, куча пользователей по всему миру. Когда у меня спрашивают о поведении продукта в той или иной не самой стандартной ситуации, как правило я отвечаю, что понятия не имею, надо в исходники смотреть и в течении 10-30 минут обычно нахожу нужный кусок кода и отвечаю. Чуть менее опытный разработчик может и 4 часа ковыряться, так и не найдя искомое. И что в таких условиях можно напланировать во время planing poker'a, сидя толпой народа в переговорке, когда практически каждая фича означает встраивание нового функционала в существующую нетривиальную архитектуру, которую полностью в уме никто не может удержать?

Здравствуйте, vpedak, Вы писали:

G>>Человеческий фактор.

V>Ну да, именно его и предлагает учитывать agile (и еще то, что требования будут изменяться). Поэтому и получается лучше, чем просто квадратики рисовать в MS Project

Квадратики в МS Project? Я думаю на этом можно завершить дискуссию...


V>дак а где я писал что оценивать не надо? Fixed price проекты они и на agile могут делаться. Понятно, что когда проект подписывают то оговаривают что вот что-то надо сделать за какое-то время и за столько-то денег.

Могут делатся, но зачем?

V>Только это описание проекта оно высокоуровневое. Разница в том какие именно и как фичи делать и с каким качеством. Это может в несколько раз менять размер реальной работы.

Т.е. скрам учитывает человеческий фактор и одновременно 100% вываливание из сроков? Я вас не понимаю.


V>ну да, конечно если команда которая реально это делает не может точно оценить, то какой-то "опытный" менеджер конечно лучше оценит... Все что он обычно и делает это закладывает дополнительное время на всякие риски (ему же по башке дадут если вовремя не успеет). Поэтому чем меньше запланируешь и чем больше заложишь на всякий-случай — тем ты более защищен.

"опытный" менеджер? нет, я говорил о тимлиде, старшем программисте и ему подобных.

V>В agile же все проще. Идет оценка производительности команды и на основании ее делается оценка когда проект будет закончен.

Полгода идет оценка производительности, потом узнают сроки

V>Но это работает только тогда когда и заказчик и исполнитель заинтересованы в результате. А не просто заинтересованы в том, чтобы какую-то хрень сдали вовремя (неважно насколько она получилась хороша и полезна).

А что, бывают не заинтересованны?

V>Ну а так как в большинстве случаев всем пофиг на реальный результат — то и agile редко где реально нужен получается.

Что за бред?

V_S>Вот тут у меня возникает логичный вопрос: а кто в этом случае "оплачивает банкет"?

А что, этот вопрос никогда не возникает в "традиционном менеджменте"?
Давайте рассмотрим типичный проект. Собственно, первую версию той же софтины. Разрабатывавшуюся той же компанией и практически той же командой (сменилось не более половины программистов).
Как все это происходит? Примерно оценивается объем работ, прикидываются фичи. Прикинули — получилось оптимистично полгода. Умножили на два, заложились на год. Периодически у менеджера спрашивали — ну как, on track? Менеджер первые полгода бодро рапортовал "да даже раньше успеем, говорили же, за полгода управимся". Вторые полгода "да, вот-вот, уже чуть-чуть осталось". Потом еще полгода "вот-вот и уже выпусим бету!"
И еще некоторое время (до его ссылки в другое место) "делаем что можем, дайте еще две недели, и выкатим что-то более-менее работающее, не более чем с сотней major bugs".
Все планы и сроки были сорваны более чем на год. Да, менеджера мягко отстранили, поставили другого, много более хитрого и скользкого. Проект сдали с грехом пополам, горой багов и годами будущей мучительной поддержки. Сколько был перерасход бюджета, мне даже представить страшно. Гарантированно больше, чем 14 двухнедельных итераций сурово поредевшей команды.
Именно это и подвигло руководство к серьезному шагу — попытке реализации SCRUM. Впрочем, по рассказам оставшихся коллег, все равно в итоге вышел фейл, т.к. уж слишком прозрачен скрам, линейному менеджменту такая прозрачность что заноза в известном месте. Да и job security страдает...

Компанию называть не хочу. Кто участвовал, тот сам знает и помнит.

V>Другое дело, что это надо чтобы и руководство это понимало и двигало скрам. Т.е. чтобы ему было выгодно реально софт делать, а не просто квадратики рисовать в microsoft project...

Кстати, это я упомянул во вступительном слове. При отсутствии реальной мотивации производить софт, хоть скрам, хоть ХР, хоть RUP — все это неважно и некритично. Можно продолжать работать "будем писать, а там, глядишь, что и получится".

V>Опять же скрам очень себя плохо показал на распределенной и интернациональной команде. Просто в силу разницы во времени и национальных особенностей не сложилась команда.

Про распределенность на 100% верно, скрам годится только для локальной команды. С проблемами интернациональности не согласен, проблем между white people не возникало никогда. Есть определенные сложности с индусами (вероятно, также будут с китайцами — но у меня такого опыта нет), решаются путем избавления от индусов.

V>Так что по мне, дак скрам очень хорош для небольштх команд когда они сидят в одном месте и реально хотят что-то сделать и имеют поддержку руководства. Во всех остальных случаях — не работает...

Именно так. Команды до 10 человек (можно несколько, работающих над разными модулями), вся команда в одном офисе, реально что-то хочет сделать, и руководству реально нужна прозрачность ситуации в проекте. Этот рецепт работает.

Проблема распределенности может сниматься путем выведения из команды удаленных людей. Проблема масштабирования — как и в традиционном варианте, решается созданием нескольких команд.
Отсутствие поддержки руководства — это, понятно, 100% фейл.

G>Да запросто. Поддержка старых версий (помощь тех.саппорту по внезапно возникшим вопросам по старым версиям), поддержка QА отдела (помощь по внезапно возникшим вопросам по текущему проекту). Если с QА можно запланировать обьем времени, то с саппортом это не выйдет.

Выйдет. Мы попробовали. Сначала было непонятно, как это закладывать. Потом накопили статистику, выяснили, что 2-3 часа в неделю уходит на консультации всякого рода 3rd line support. В итоге, из "доступного времени" каждого спринта вычитали 6 часов (брали верхнюю границу, если потребуется меньше — отлично, поможем товарищам).

G>Так я и не понял, откуда у вас такое понятие, что разработчик должен "переступить через свой стыд и признатся" сколько времени он потратит на следущий спринт?

Вопрос ваш снова подчеркивает — вы никогда не пробовали это всерьез. Иначе бы он не возникал. Знаете, разработчикам как-то очень неприятно выдавать оценки "в следующие две недели только 28 часов я буду приносить пользу проекту", когда начальство (в роли silent spectator присутствующее на входе в итерацию) молчит, но цвет лица меняет с розового на багровый и алый.

G>Вы в этом уверенны? Это аксиома традиционного менеджмента? У вас был печальный личный опыт?

Да. В этом самом менеджменте описанные вами "поддержка предыдущий версий" и прочий саппорт не имеют ни четкого time-boxing'а, ни нормального планирования. Зачастую и вовсе идут по принципу "поработаете в выходной день".

G>Вот тут кстати интересно насчет самоконтроля. Поигрался народ в покер, начали спринт, потратили 15 часов на фейсбук, после замерили велосити. Новый спринт, опять фейсбук, велосити таже. В относительных числах фибоначчи все выглядит гладко. Не у кого звоночек не зазвонит.

Не зазвенит? Значит, руководство считает нормальной такую скорость команды. Ровно с тем же успехом в традиционном варианте разработчики объяснят — "вот, занимались этим и этим, успели только это". С одной лишь разницей — все это выяснится не через две недели, а через полгода, когда ничего не сделано и, соответственно, не работает. Потому что начальство поверило словам менеджера. Который, в свою очередь, также положился на разработчиков. Ну а с их точки зрения и так все работает! На их машинах.
Уверяю вас, с точки зрения менеджмента очень важно иметь прозрачное видение того, в каком состоянии проект. Именно для этого нужны спринты — итерации, на выходе из которых есть рабочий (в идеале — готовый к релизу) продукт.

G>За полтора десятка лет я чем только не занимался и даже в скраме имел честь несколько лет поучаствовать.

За несколько лет скрама вы так и не смогли понять его основ? Просите, видимо, вы ошибочно принимали СкрамНо за скрам.

G>Сколько потребуется с учетом фейсбуков — нет конечно. Но запросто может достаточно точно оценить за какое время именно данный разработчик с конкретной компетенцией ее может сделать.

"Жираф большой, ему видней" (С)
Вы заблуждаетесь. В книге Mythical Man-Month подобные заблуждения очень хорошо описаны. Рекомендую.

G>Это естественно, опиратся на экспертную сложность задачи с дальнейшим учетом способностей резработчика. Это почти что ваши стори поинты только с дополнительной точностю, т.к. учитывается индивидуальная "велосити" а не средняя по больнице.

Ага, и если Вася заболел, все оценки идут насмарку. Что уж говорить, если Вася вдруг уволится. Весь проект придется переделать, никто же не знает, что там Вася колбасил. Яркое проявление традиционного менеджмента.

G>Участвовал и проводил.

Не является ли секретной информация, где и как? К сожалению, о вас нет никакой информации в профиле. Возможно, осознание вашего опыта потребует пересмотреть мои позиции с учетом вашего опыта.

G>Привлекали специалистов, платили, кстати им кучу баблосов. Итог не порадовал. Скорость разработки и качество то же.

Погодите. А вы чего ожидали? Что у вас улучшится скорость или качество? Тогда вы точно обратились не туда. Эти методики нужны для получения предсказуемости и завершаемости проекта. Иными словами, для организации прозрачности и управляемости. Это инструменты для быстрой оценки любых изменений — "что будет, если мы вот это добавим, а вот это выкинем". Это способ мгновенно осознать — "если Вася уйдет, проект завершится на три месяца позднее, или придется урезать функционал, или снизими требования к багам".

SD>>В классическом scrum-by-the-book не выделяется персональная производительность члена команды.
G>Это и плохо. Очень плохо.

Для тех, кто не умеет работать с командой — может и так. Иными словами, результаты неприменимы для шарлатанства вида "аттестация" и прочих appraisal, синонимов субъективного отношения начальника к конкретному члену команды. Что уж там, скрам на святое покушается — на линейный менеджмент За что и должен быть предан анафеме.

Целью таких методик является производство продукта. Целью всякого рода "начальников" является извлечение прибыли для себя. Если эти цели находятся на одном векторе (начальник — основной бенифициар), тогда скрам катит. Если начальник получает деньги "подушно" за количество работников, скрам и agile невыгодны и обречены на провал, как верно заметил Вячеслав.

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

Ровно так же не оценить ни время, ни деньги в предлагаемом вами подходе. Потому что оценки с потолка начальника касаемо своих подчиненных вида "Вася это сделает за три дня" ничуть не менее относительны, чем SP. Разница только в том лукавстве, с которыми преподносятся абсолютные оценки, и с тем, что следует при ошибке в прогнозе. Заметьте абсурдность ситуации — начальник оценил в 3 дня, Вася делал 8, виноват, как правило, Вася — "плохо работал".

G>Вы наверное удивитесь, но проект с грамотным тимлидом при классике завершается в худшем случае за такое же время с теми же фичами и с таким же кол-вом багов как и при скраме под чутким руководством самого супер-пупер скрам специалиста.

Не знаю, что вы вкладываете в понятие "классика", но вполне могу в это поверить. Ничего удивительного для первых опытов с любой новой методикой. Но — есть один нюанс: в случае со скрам вся жизнь проекта сохранена в истории разработки. В любой момент было ясно, что происходит. В любой момент можно было изменить что угодно — от функционала (scope) до состава команды. Представьте, что в таком варианте происходит с "классикой".

G>И что произошло потом? Вы попросили у заказчика еще столько же денег или обьявили себя банкротом? В этом вся "прелесть" скрама. Узнать "потянем-не потянем" в середине распила.

Да, именно в этом прелесть первого опыта внедрения. Узнать всего лишь через полгода, а не через год, что ничего не выходит. И таки да, для проектов того масштаба это было весьма ранним обнаружением — по традиционному варианту, я уверен, пилили бы еще не меньше полугода (потом закрыли бы, а может, и доделали бы — для хоть какой-то компенсации убытков).

Если бы члены команды уже имели бы опыт скрам — все выяснилось бы через 2-3 месяца.

G>Я вообще не сказал, что скрам плох. Есть в нем положительные моменты, но бардака там полно, как бы вы тут его медом не мазали.

Как раз бардака — минимум.
Сложности только с поддержкой руководства. Надо, чтобы целью руководства было именно создание софта, а не набор поголовья программистов для обоснования повышения собственной зарплаты.

V_S>Хорошо. Ты можешь еще до начала проекта по скраму/эджайлу/etc. четко сказать Заказчику — когда проект будет закончен и сколько денег на это потребуется?

КО в студии. До начала проекта никакого скрама/agile нет и быть не может.

Все сколь-нибудь серьезные проекты (в т.ч. заказные) делаются поэтапно. Через стадии концепта и прототипа до RTM. Чем ближе к завершению — тем точнее оценка.
Гуглить по ключевым словам cone of uncertainty.

V_S>Так вот, уверяю тебя: если в "традиционном" менеджменте реализованный функционал также оставить на усмотрение менеджера проекта — с определенной (и достаточно большой) степенью свободы и грамотно расставленными приоритетами фич, — то и "традиционно" управляемые проекты вдруг перестанут вываливаться из сроков и бюджета.

В теории, да. На практике — нет. Потому что именно итеративная разработка с жестко выделенными критериями Definition of Done является визитной карточкой SCRUM и основной его идеей. В традиционном варианте, теоретически, итерации тоже имеют место быть. Но что я видел на практике — постоянно разобранный trunk и вечные "стабилизационные ветки".

T>Проблема planning poker в том, что он таки дает оценку с потолка, хоть и согласованную между членами команды. Это происходит из-за того, что во время оценки члены команды зачастую не знают как именно они будут эту фичу реализовывать, надеясь сориентироваться в процессе её выполнения. У них просто нет времени и возможности хорошо подумать и покопаться в исходниках.

Мы сталкивались с этой проблемой. И успешно ее преодолели итерации этак к шестой, заложив 2 часа на pre-planning meeting, время, которое как раз уходит на "посмотреть в код" и пообщаться с коллегами из других команд.
Как я уже писал — надо быть честным. Если для обдумывания фичи требуется заглянуть в код — надо учесть это время.

На planning poker команда приходит подготовленной.

V>>дак а где я писал что оценивать не надо? Fixed price проекты они и на agile могут делаться. Понятно, что когда проект подписывают то оговаривают что вот что-то надо сделать за какое-то время и за столько-то денег.
G>Могут делатся, но зачем?

Fixed all, как тот самый мифический единорог, могут делаться на чем угодно. Их все равно не существует. Основная хитрость этих самых fixed all — умение засунуть variable часть в подготовку к проекту. Которая как бы не учитывается, или учитывается по факту — например, по осознанию факта, что на подготовку и согласование всех требований ушло вот столько-то.

G>Т.е. скрам учитывает человеческий фактор и одновременно 100% вываливание из сроков? Я вас не понимаю.

Скрам не манипулирует сроками. Само понятие срока в скрам отсутствует. Есть только итерации, спринты. Если вы годами работали по скрам, зачем вы задаете такие вопросы?

G>"опытный" менеджер? нет, я говорил о тимлиде, старшем программисте и ему подобных.

Всегда забавлял этот подход. Вы бы хотели, чтобы Вася за вас оценивал, сколько вы потратите на ту или иную фичу? Или вы думаете, что раз вы теперь "старший программист", вам сие не грозит, и только вы будете заниматься сочинительством и гаданием по кофейной гуще за Петю и Колю?

G>Полгода идет оценка производительности, потом узнают сроки

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

G>А что, бывают не заинтересованны?

Именно так. В значительной части случаев ни команда, ни ее руководство не заинтересованы в производстве продукта. Их интерес в получении зарплаты. Чем дольше и чем в бОльшем количестве они будут ее получать, тем для них лучше. С этой точки зрения выгоднее содержать состояние проекта в тумане. И через год поставить перед фактом — надо еще год и больше людей. Компании, уже столько вложившей в проект и давшей обязательства перед партнерами, придется идти на уступки. Если бы все это было известно полгода назад — с высокой долей вероятности компания бы просто зафиксировала убытки и отменила продукт.

Здравствуйте, SkyDance, Вы писали:

SD>В теории, да. На практике — нет. [....] Но что я видел на практике — постоянно разобранный trunk и вечные "стабилизационные ветки".

По-видимому, это как раз и зависит от личного опыта. У меня это самый личный опыт — положительный: проекты были сданы в срок и уложились в бюджет. (Да, менеджились они — "традиционно", а вот объемом функционала можно было управлять....)

Здравствуйте, SkyDance, Вы писали:

V_S>>Вот тут у меня возникает логичный вопрос: а кто в этом случае "оплачивает банкет"?

SD>А что, этот вопрос никогда не возникает в "традиционном менеджменте"?
SD>Давайте рассмотрим типичный проект. Собственно, первую версию той же софтины. Разрабатывавшуюся той же компанией и практически той же командой (сменилось не более половины программистов).
SD>Как все это происходит? Примерно оценивается объем работ, прикидываются фичи. Прикинули — получилось оптимистично полгода. Умножили на два, заложились на год. Периодически у менеджера спрашивали — ну как, on track? Менеджер первые полгода бодро рапортовал "да даже раньше успеем, говорили же, за полгода управимся". Вторые полгода "да, вот-вот, уже чуть-чуть осталось". Потом еще полгода "вот-вот и уже выпусим бету!"
SD>И еще некоторое время (до его ссылки в другое место) "делаем что можем, дайте еще две недели, и выкатим что-то более-менее работающее, не более чем с сотней major bugs".
SD>Все планы и сроки были сорваны более чем на год. Да, менеджера мягко отстранили, поставили другого, много более хитрого и скользкого. Проект сдали с грехом пополам, горой багов и годами будущей мучительной поддержки. Сколько был перерасход бюджета, мне даже представить страшно. Гарантированно больше, чем 14 двухнедельных итераций сурово поредевшей команды.
SD>Именно это и подвигло руководство к серьезному шагу — попытке реализации SCRUM. Впрочем, по рассказам оставшихся коллег, все равно в итоге вышел фейл, т.к. уж слишком прозрачен скрам, линейному менеджменту такая прозрачность что заноза в известном месте. Да и job security страдает...

SD>Компанию называть не хочу. Кто участвовал, тот сам знает и помнит.

Такими страшилками обычно промывают моск на вступительном часе на скрам тренингах.

Здравствуйте, Vlad_SP, Вы писали:

V_S>Так вот, уверяю тебя: если в "традиционном" менеджменте реализованный функционал также оставить на усмотрение менеджера проекта — с определенной (и достаточно большой) степенью свободы и грамотно расставленными приоритетами фич, — то и "традиционно" управляемые проекты вдруг перестанут вываливаться из сроков и бюджета.

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

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

Здравствуйте, SkyDance, Вы писали:


G>>Так я и не понял, откуда у вас такое понятие, что разработчик должен "переступить через свой стыд и признатся" сколько времени он потратит на следущий спринт?

SD>Вопрос ваш снова подчеркивает — вы никогда не пробовали это всерьез. Иначе бы он не возникал. Знаете, разработчикам как-то очень неприятно выдавать оценки "в следующие две недели только 28 часов я буду приносить пользу проекту"

Я так и не понял, что же тут неприятного если на то есть обьяснение уважительной причины?! У ваших людей проблемы с психикой или они настолько не адекватны, что не могут обьяснить причины?

G>>Вы в этом уверенны? Это аксиома традиционного менеджмента? У вас был печальный личный опыт?

SD>Да. В этом самом менеджменте описанные вами "поддержка предыдущий версий" и прочий саппорт не имеют ни четкого time-boxing'а, ни нормального планирования. Зачастую и вовсе идут по принципу "поработаете в выходной день".

Да откуда вы взяли эту чушь? Такое впечатление, что вы со школьной скамьи попали на скрам тренинг и потом в скрам команду, где и по сей день.

G>>Вот тут кстати интересно насчет самоконтроля. Поигрался народ в покер, начали спринт, потратили 15 часов на фейсбук, после замерили велосити. Новый спринт, опять фейсбук, велосити таже. В относительных числах фибоначчи все выглядит гладко. Не у кого звоночек не зазвонит.

SD>Не зазвенит? Значит, руководство считает нормальной такую скорость команды.

Как в скраме руководство может оценить скорость команды если она величина постоянная? Кстати, руководство вы имеете ввиду: скрам-мастер, продакт оунер?

SD>Ровно с тем же успехом в традиционном варианте разработчики объяснят — "вот, занимались этим и этим, успели только это".

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

SD>С одной лишь разницей — все это выяснится не через две недели, а через полгода

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

SD>Уверяю вас, с точки зрения менеджмента очень важно иметь прозрачное видение того, в каком состоянии проект. Именно для этого нужны спринты — итерации, на выходе из которых есть рабочий (в идеале — готовый к релизу) продукт.

Да с чего вы взяли, что его нет в традиционной разработке? Проeкт на стадии планирования делится на модули и подзадачи, для которых определены свои сроки (кстати также с учетом техподдержки, болезней и тд.)

G>>За полтора десятка лет я чем только не занимался и даже в скраме имел честь несколько лет поучаствовать.

SD>За несколько лет скрама вы так и не смогли понять его основ? Просите, видимо, вы ошибочно принимали СкрамНо за скрам.

Я понял основы и детали, и вижу его преимущества и кучу недостатков. Может это вам надо попробовать снять розовые очки?

G>>Это естественно, опиратся на экспертную сложность задачи с дальнейшим учетом способностей резработчика. Это почти что ваши стори поинты только с дополнительной точностю, т.к. учитывается индивидуальная "велосити" а не средняя по больнице.

SD>Ага, и если Вася заболел, все оценки идут насмарку. Что уж говорить, если Вася вдруг уволится. Весь проект придется переделать, никто же не знает, что там Вася колбасил. Яркое проявление традиционного менеджмента.

Вот знание о том, что колбасил Вася вточности одинаково как в традиционной разработке, так и в скраме. Не надо опять все красить в черно-белое.

G>>Привлекали специалистов, платили, кстати им кучу баблосов. Итог не порадовал. Скорость разработки и качество то же.

SD>Погодите. А вы чего ожидали? Что у вас улучшится скорость или качество? Тогда вы точно обратились не туда. Эти методики нужны для получения предсказуемости и завершаемости проекта. Иными словами, для организации прозрачности и управляемости. Это инструменты для быстрой оценки любых изменений — "что будет, если мы вот это добавим, а вот это выкинем". Это способ мгновенно осознать — "если Вася уйдет, проект завершится на три месяца позднее, или придется урезать функционал, или снизими требования к багам".

предсказуемости и завершаемости — спасибо, посмеялся.

SD>>>В классическом scrum-by-the-book не выделяется персональная производительность члена команды.
G>>Это и плохо. Очень плохо.

SD>Для тех, кто не умеет работать с командой — может и так. Иными словами, результаты неприменимы для шарлатанства вида "аттестация" и прочих appraisal, синонимов субъективного отношения начальника к конкретному члену команды. Что уж там, скрам на святое покушается — на линейный менеджмент За что и должен быть предан анафеме.

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

SD>Целью таких методик является производство продукта. Целью всякого рода "начальников" является извлечение прибыли для себя. Если эти цели находятся на одном векторе (начальник — основной бенифициар), тогда скрам катит. Если начальник получает деньги "подушно" за количество работников, скрам и agile невыгодны и обречены на провал, как верно заметил Вячеслав.

Целью любых методик является производство продукта. Целью любого чека, кто участвует в разработке продукта есть персональный профит. У каждого он разный, но в основном: деньги или слава. (с) КО

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

SD>Ровно так же не оценить ни время, ни деньги в предлагаемом вами подходе. Потому что оценки с потолка начальника касаемо своих подчиненных вида "Вася это сделает за три дня" ничуть не менее относительны, чем SP. Разница только в том лукавстве, с которыми преподносятся абсолютные оценки, и с тем, что следует при ошибке в прогнозе. Заметьте абсурдность ситуации — начальник оценил в 3 дня, Вася делал 8, виноват, как правило, Вася — "плохо работал".

начальника? ну скажем так: более опытного, старшего программиста, который делал подобное уже раньше и к тому же знает квалификацию юниора, которому предстоит занятся данной задачей первый раз в жизни.

G>>И что произошло потом? Вы попросили у заказчика еще столько же денег или обьявили себя банкротом? В этом вся "прелесть" скрама. Узнать "потянем-не потянем" в середине распила.

SD>Да, именно в этом прелесть первого опыта внедрения. Узнать всего лишь через полгода, а не через год, что ничего не выходит. И таки да, для проектов того масштаба это было весьма ранним обнаружением — по традиционному варианту, я уверен, пилили бы еще не меньше полугода (потом закрыли бы, а может, и доделали бы — для хоть какой-то компенсации убытков).

Опять страшилки с вводной части курса по скраму. Узнаю

SD>Если бы члены команды уже имели бы опыт скрам — все выяснилось бы через 2-3 месяца.

Все же мне интересно, что вы говорите заказчику? "Ну мы начнем делать то, что вы хотите, а через 3 месяца мы вам назовем сроки и цену. Подождите чутка, у нас опытная команда, не ищити другую фирму, плиииз"

G>>Я вообще не сказал, что скрам плох. Есть в нем положительные моменты, но бардака там полно, как бы вы тут его медом не мазали.

SD>Как раз бардака — минимум.

Не хаос конечно, но бардака очень много.

Здравствуйте, SkyDance, Вы писали:


G>>Т.е. скрам учитывает человеческий фактор и одновременно 100% вываливание из сроков? Я вас не понимаю.

SD>Скрам не манипулирует сроками. Само понятие срока в скрам отсутствует. Есть только итерации, спринты. Если вы годами работали по скрам, зачем вы задаете такие вопросы?

понятие срока в скрам отсутствует, но в планировании и менеджменте присутствует у любого проекта и вываваливание из сроков это как раз из вашего примера как через полгода узнают что "непотянут"

G>>"опытный" менеджер? нет, я говорил о тимлиде, старшем программисте и ему подобных.

SD>Всегда забавлял этот подход. Вы бы хотели, чтобы Вася за вас оценивал, сколько вы потратите на ту или иную фичу? Или вы думаете, что раз вы теперь "старший программист", вам сие не грозит, и только вы будете заниматься сочинительством и гаданием по кофейной гуще за Петю и Колю?

нет никакого гадания. У вас просто мало опыта, скорее всего. Потом никто и не говорил, что тимлид ставит сроки в одиночку. Он таки общается со всеми программистами, просто учитывает их оценки с дополнительным индивидуальным коэффициентом.

G>>Полгода идет оценка производительности, потом узнают сроки

SD>Для команды, которая впервые в жизни столкнулась со скрам, это нормальный результат. В дальнейшем требуется меньше времени. Для сравнения можно взять новичка-тимлида. Думаете, он ошибется на меньшие величины?

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

G>>А что, бывают не заинтересованны?

SD>Именно так. В значительной части случаев ни команда, ни ее руководство не заинтересованы в производстве продукта. Их интерес в получении зарплаты. Чем дольше и чем в бОльшем количестве они будут ее получать, тем для них лучше. С этой точки зрения выгоднее содержать состояние проекта в тумане. И через год поставить перед фактом — надо еще год и больше людей. Компании, уже столько вложившей в проект и давшей обязательства перед партнерами, придется идти на уступки. Если бы все это было известно полгода назад — с высокой долей вероятности компания бы просто зафиксировала убытки и отменила продукт.

Вы хотите сказать, что скрам полезно и нужно применять в командах, где малая заинтересованность в конечном продукте, для полного контроля ситуации со стороны заказчика? Т.е. он раз в три недели будет присутствовать на демонстрационных показах фич в конце спринта и тем самым контролировать, если его не кинут со сроками и деньгами? А если там все сгнило внутри (лишь бы уложится в итерацию) и ближе к концу проекта начинаются постоянные рефакторинги, скорость и качество падают потому что первые итерации говнокодили в основном для демо? Где контроль? Скрам не содержит сосотяние проекта в тумане?

Здравствуйте, goondick, Вы писали:

G>Здравствуйте, SkyDance, Вы писали:

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

SD>>С одной лишь разницей — все это выяснится не через две недели, а через полгода

G>Почему через пол-года. Есть модули которые надо сдавать в определенные сроки, тестировать, сдавать на ревью, в QA ит.д. Отличие от скрама только в том что сроки задач более логичные и варьируются в разумных пределах в зависимости от сложности задачи, а не фиксированные искусственно-раскроенные на равные части итерации как в скраме.

А как еще в традиционном менджменте вы будете решать проблему с изменяющимися сроками? Заболел у вас программист и модуль А не был сделан в срок. А через три месяца после начала проекта вышла библиотека, которая позволит не делать модуль Б, на который в будущем был выделен месяц.

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

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

И все вышесказанное справедливо даже при том, что ТЗ фиксированное. А оно далеко не всегда фиксированное. Клиент, увидев начальный результат, может что-то изменить в проекте. Оказывается, какие-то задачи он может выполнить раньше/более простыми средствами, но при разработке ТЗ забыл совершенно про другую важную задачу.

SD>>Уверяю вас, с точки зрения менеджмента очень важно иметь прозрачное видение того, в каком состоянии проект. Именно для этого нужны спринты — итерации, на выходе из которых есть рабочий (в идеале — готовый к релизу) продукт.

G>Да с чего вы взяли, что его нет в традиционной разработке? Проeкт на стадии планирования делится на модули и подзадачи, для которых определены свои сроки (кстати также с учетом техподдержки, болезней и тд.)

Вы забываете самый большой риск для "модульного" проекта — интеграция всех модулей в единое целое. Ее очень сложно планировать, там всплывают различные баги, допущенные на начальных этапах (что-то не оттестировали, что-то не заложили в спецификацию). В хронических случаях может доходить до того, что проще переделать какой-то модуль, чем интегрировать его в остальную систему. Гораздо более реалистичным и управляемым является не план в терминах "модулей", а в терминах "функциональность, реализуемая продуктом". Т.е. интеграция с самого начала. А это основной постулат вообще всех Agile. И наличие/отсутствие функциональности прекрасно видно (в отличие от модулей, которые по-отдельности работают хорошо, но нужно потратить кучу времени на их интеграцию). Ну а дальше добавляем различные стратегии оперативного управления и получаем различные варианты Agile.


SD>>>>В классическом scrum-by-the-book не выделяется персональная производительность члена команды.
G>>>Это и плохо. Очень плохо.

SD>>Для тех, кто не умеет работать с командой — может и так. Иными словами, результаты неприменимы для шарлатанства вида "аттестация" и прочих appraisal, синонимов субъективного отношения начальника к конкретному члену команды. Что уж там, скрам на святое покушается — на линейный менеджмент За что и должен быть предан анафеме.

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

Вообще-то, "психологическую составляющую" никто не убирает. Она остается. "Сделал фичу А", "Помог Васе сделать фичу Б". "Обнаружил на ревью типичную ошибку и на уровне всей команды решил проблему". Ну да, теряется гордость за "сделал очередной велосипед с квадратными колесами". Но вместо нее есть та самая "сделал фичу Х". И это гораздо более приятно, так как результат сразу виден в командном продукте. Теряется и возможность клепать говнокод в одиночку (оправдывая это тем, что "модуль мой"), но зато при нормальном коде приятно его признание всей командой. Собственно, страх показать свой код обычно свидетельствует о том, что там все очень и очень плохо.

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

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

Ах да, забыл. Здесь больше всего страдает менеджер, а не программисты . Вот ему не получится изображать бурную деятельность и валить все проблемы на программистов. Работать ему придется, объяснять заказчикам и программистам, какие задачи решает scrum или любой другой процесс разработки. Следить за текущим состоянием дел, анализировать проблемы, принимать меры к их устранениню. Но если не лениться это делать, и менеджер/мастер может гордиться результатами своего труда (а также сроками/качестовм и т.п.) и продуктом, который команда сделала.

G>начальника? ну скажем так: более опытного, старшего программиста, который делал подобное уже раньше и к тому же знает квалификацию юниора, которому предстоит занятся данной задачей первый раз в жизни.

А вы с юниорами тесно работали? Нельзя узнать, сколько у юниора займет более-менее реальная задача. Можно дать кодить готовый дизайн, но это совсем не интересно и юниора не тренирует. А если давать что-то чуть более сложное, возможны варианты:
1. Начальное решение будет "совсем не в тему". Это нужно отлавливать, предлагать (именно предлагать, а не навязывать) свое решение, обсуждать варианты и т.п.
2. Решение в более/менее предлагаемом варианте. Тут просто нужно следить за скоростью реализации.
3. Предложен вариант лучше, чем предполагался. Здесь скорость реализации будет даже быстрее, чем изначально планировалось.
4. Предложен "оригинальный" вариант и сложно сказать, что выйдет. Здесь нужно экспериментировать, смотреть. И нужно сам процесс принятия решения организовывать.
В общем, не все так просто. Тот же scrum предполагаемое решение согласует на scrum-meeting'е и со сроками будет определенность.

А еще производительность плавает по мере набора опыта и т.п. И переход от "пишем в три итерации под надзором" до "оно работает и есть интересные решения". Плавает она и по внешним причинам (как и у других членов команды). И уж тем более плохо с оценкой новых задач для Junior'а. Может, он не делал ничего ни разу, но у него отличная теоретическая подготовка и задачу он сделает быстро. Или, наоборот, не получается у него какая-то одна тема (даже у опытных разработчиков есть слабые и сильные места).

В общем, с юниорами как раз получается "agile в миниатюре" с планированием в рамках "небольшой командной итерации" и этапами "1-2 дня", контролем, принятием при необходимости мер и т.п. И ни в коем случае не "классическое планирование".

SD>>Если бы члены команды уже имели бы опыт скрам — все выяснилось бы через 2-3 месяца.

G>Все же мне интересно, что вы говорите заказчику? "Ну мы начнем делать то, что вы хотите, а через 3 месяца мы вам назовем сроки и цену. Подождите чутка, у нас опытная команда, не ищити другую фирму, плиииз"

Нормальному заказчику в общих чертах объясняется процесс. То, что через 2 недели будет минимальный набор функциональности, через 1 месяц функциональности будет чуть больше и т.д. И при этом по завершении двухнедельной итерации можно будет покрутить продукт, спланировать его дальнейшее развитие и т.п. Можно также рассказать о типичных сложностях планирования "fixed cost", незавершающихся проектах и т.п. Ну да, заказчику придется поднапрячься и понять, что же будет происходить. Но зато если он разберется, получит возможность управлять затратами, возможность закрыть проект (если он не выгоден) и т.п. Это нормальное управление рисками. А вот "отдать проект реализовывать на три месяца без вестей с фронта" можно только если за просрочку/недостаточную функциональнось предусмотрена хорошая неустройка. Но ведь не пойдут на это компании, разрабатывающие по классике.

Здравствуйте, goondick, Вы писали:


G>>>Полгода идет оценка производительности, потом узнают сроки

SD>>Для команды, которая впервые в жизни столкнулась со скрам, это нормальный результат. В дальнейшем требуется меньше времени. Для сравнения можно взять новичка-тимлида. Думаете, он ошибется на меньшие величины?

G>Представьте на минуточку разбить задачу на подзадачи, оценить сроки выполнения подзадач. По мере реального выполнения подзадач корректировать сроки или ресурсы проекта.

А возможные проблемы при выполнении задач оценить? Например, не сработает по каким-то критериям подход, который предполагался для решения задач.

Да и корректирование "срок/ресурсы" — это уже шаги к Agile (большой план вам только зависимости между компонентами будет показывать). Но нужно еще и функционал корректировать. Может быть выгоднее менее функциональная программа в более короткий срок, чем полнофункциональная программа за долгий срок.

G>>>А что, бывают не заинтересованны?

SD>>Именно так. В значительной части случаев ни команда, ни ее руководство не заинтересованы в производстве продукта. Их интерес в получении зарплаты. Чем дольше и чем в бОльшем количестве они будут ее получать, тем для них лучше. С этой точки зрения выгоднее содержать состояние проекта в тумане. И через год поставить перед фактом — надо еще год и больше людей. Компании, уже столько вложившей в проект и давшей обязательства перед партнерами, придется идти на уступки. Если бы все это было известно полгода назад — с высокой долей вероятности компания бы просто зафиксировала убытки и отменила продукт.

G>Вы хотите сказать, что скрам полезно и нужно применять в командах, где малая заинтересованность в конечном продукте, для полного контроля ситуации со стороны заказчика? Т.е. он раз в три недели будет присутствовать на демонстрационных показах фич в конце спринта и тем самым контролировать, если его не кинут со сроками и деньгами? А если там все сгнило внутри (лишь бы уложится в итерацию) и ближе к концу проекта начинаются постоянные рефакторинги, скорость и качество падают потому что первые итерации говнокодили в основном для демо? Где контроль? Скрам не содержит сосотяние проекта в тумане?

Таки не держит. Нету в скраме (да и другом agile) демо. Просто нет! Есть полноценный программный продукт с урезанной (может быть — очень сильно) функциональностью. И заказчик видит продукт не на презентации, а у себя. Уже после первой (это в идеале, но в любом случае после небольшого количества) итерации производится внедрение. Все, можно гонять, искать баги, проверять функциональность. Если за следующую итерацию заказчик не нашел бага, видимо, это совсем не критичный баг (за 2-3 недели функция не проверялась или не использовалась, например).

С деньгами "по-крупному" при таком подходе кинуть сложно. Продукт же передается заказчику и риск в пределах 1-3 итераций (зависит от активности использования и т.п.). Явно меньше, чем при водопаде на полгода. А то, что внутри, никого при грамотном риск-менеджменте не интересует. Вся критичная/важная функциональность будет реализована в начальных итерациях и если какие-то рюшечки сдохнут под тяжестью проекта, почти никто расстраиваться не будет (ну да, разработчики во главе с менеджером меньше денег получат).

On 27.08.2012 15:17, maxkar wrote:
> А если
> там все сгнило внутри (лишь бы уложится в итерацию) и ближе к концу
> проекта начинаются постоянные рефакторинги, скорость и качество падают
> потому что первые итерации говнокодили в основном для демо? Где
> контроль? Скрам не содержит сосотяние проекта в тумане?
>
> Таки не держит. Нету в скраме (да и другом agile) демо. Просто нет! Есть
> полноценный программный продукт с урезанной (может быть — очень сильно)
> функциональностью. И заказчик видит продукт не на презентации, а у себя.
> Уже после первой (это в идеале, но в любом случае после небольшого
> количества) итерации производится внедрение. Все, можно гонять, искать
> баги, проверять функциональность. Если за следующую итерацию заказчик не
> нашел бага, видимо, это совсем не критичный баг (за 2-3 недели функция
> не проверялась или не использовалась, например).

Мне неясно как это уменьшает вероятность того, что "ближе к концу
проекта начинаются постоянные рефакторинги, скорость и качество падают
потому что первые итерации говнокодили в основном для демо". Ну заменим
слово "демо" на "полноценный программный продукт с урезанной (может быть
— очень сильно) функциональностью."
Речь про стоимость добавления фич, превращающих "то, что вообще можно
где-нибудь развернуть" в то, "что имеет для заказчика бизнес-смысл". Или
вы хотите сказать, что этого в среднем можно достичь за месяц-полтора?
SkyDance тут рассказывал что-то про полгода что ли, после которого
решили, что пора завязывать — ничего не выходит.

--
WBR,
Serge.

Здравствуйте, maxkar, Вы писали:

M>Здравствуйте, goondick, Вы писали:


G>>>>Полгода идет оценка производительности, потом узнают сроки

SD>>>Для команды, которая впервые в жизни столкнулась со скрам, это нормальный результат. В дальнейшем требуется меньше времени. Для сравнения можно взять новичка-тимлида. Думаете, он ошибется на меньшие величины?

G>>Представьте на минуточку разбить задачу на подзадачи, оценить сроки выполнения подзадач. По мере реального выполнения подзадач корректировать сроки или ресурсы проекта.

M>А возможные проблемы при выполнении задач оценить? Например, не сработает по каким-то критериям подход, который предполагался для решения задач.

И? Скрам как эти проблемы решает? Не срабатывает подход решения задачи, вместо 1 "енота"SP задача будет внезапно весить 16 "енотов" SP. Отлично, все что посчитали ранее по велосити и SP можно считать недействительным. В чем разница эпического фейла с менежерской точки зрения на эту проблему?

M>Может быть выгоднее менее функциональная программа в более короткий срок, чем полнофункциональная программа за долгий срок.

G>>>>А что, бывают не заинтересованны?


M>Нету в скраме (да и другом agile) демо. Просто нет! Есть полноценный программный продукт с урезанной (может быть — очень сильно) функциональностью. И заказчик видит продукт не на презентации, а у себя. Уже после первой (это в идеале, но в любом случае после небольшого количества) итерации производится внедрение. Все, можно гонять, искать баги, проверять функциональность. Если за следующую итерацию заказчик не нашел бага, видимо, это совсем не критичный баг (за 2-3 недели функция не проверялась или не использовалась, например).

Именно демонстрацией какой-либо фичи (натянутой за уши как готовой) заказчик всегда и ограничивался на практике.
1. Фича очень часто зависит от другой, которая будет готова в след. итерации.
2. Даже полнофункциональная фича часто теряет смысл в практическом применении в технологическом процессе, пока не будет готова большая часть продукта.
3. Продукт после нескольких итераций используется пару людьми из тех.отдела в рамках тестирования, теми кто ответственный за финальное внедрение. Много они его натестируют в отрыве от "реальной жизни"? Даже если условия позволяют подключить к процессу тестирования всю фирму, у тех.персонала просто физически не будет возможности к дистибуции версий, обучения и сбора багрепортов каждые 3 недели.

Сладкая утопия из книжек по скраму.ки сдохнут под тяжестью проекта, почти никто расстраиваться не будет (ну да, разработчики во главе с менеджером меньше денег получат).

Здравствуйте, maxkar, Вы писали:


M>А как еще в традиционном менджменте вы будете решать проблему с изменяющимися сроками? Заболел у вас программист и модуль А не был сделан в срок. А через три месяца после начала проекта вышла библиотека, которая позволит не делать модуль Б, на который в будущем был выделен месяц.

Ну вот вы сами и ответили, как одно компенсирует другое

M>И вопрос здесь даже не в сроках. Скрам (да и весь Agile) не пытается решить проблему определения сроков всего проекта. Но при этом позволяет оперативно реагировать на ситуацию и балансировать в рамках треугольника сроки/качество/функционал. Если все три параметра фиксированы, ничего нового и интересного (кроме раннего обнаружения невыполнения проекта) вы не получите.

"сроки/качество/функционал" — в чем разница баллансирования в других видах разработки?

M>Если же начальный план включает раннюю и постоянную интеграцию модулей, то ваш scrum будет идти "поверх" исходного плана. Т.е. компонент А так и будет выбран в работу, когда пришла его очередь по плану (все зависимости уже реализованы, например). А вот если зависимости не реализованы, сразу станут видны проблемы на проекте.

M>И все вышесказанное справедливо даже при том, что ТЗ фиксированное. А оно далеко не всегда фиксированное. Клиент, увидев начальный результат, может что-то изменить в проекте. Оказывается, какие-то задачи он может выполнить раньше/более простыми средствами, но при разработке ТЗ забыл совершенно про другую важную задачу.

Ну и в чем проблема? Захотел изменить функционал, вспомнил о важной фиче посередине проекта. Составляем изменение ТЗ, оговариваем сроки, деньги, едем дальше.


M>Вы забываете самый большой риск для "модульного" проекта — интеграция всех модулей в единое целое. Ее очень сложно планировать, там всплывают различные баги, допущенные на начальных этапах (что-то не оттестировали, что-то не заложили в спецификацию). В хронических случаях может доходить до того, что проще переделать какой-то модуль, чем интегрировать его в остальную систему. Гораздо более реалистичным и управляемым является не план в терминах "модулей", а в терминах "функциональность, реализуемая продуктом". Т.е. интеграция с самого начала. А это основной постулат вообще всех Agile. И наличие/отсутствие функциональности прекрасно видно (в отличие от модулей, которые по-отдельности работают хорошо, но нужно потратить кучу времени на их интеграцию). Ну а дальше добавляем различные стратегии оперативного управления и получаем различные варианты Agile.

<...в терминах "модулей", а в терминах "функциональность, реализуемая продуктом". Т.е. интеграция с самого начала.> — кхм... что это? как это увязать с выдачей фичи народу в пользование каздые три недели?


M>А вы с юниорами тесно работали? Нельзя узнать, сколько у юниора займет более-менее реальная задача. Можно дать кодить готовый дизайн, но это совсем не интересно и юниора не тренирует. А если давать что-то чуть более сложное, возможны варианты:
M> 1. Начальное решение будет "совсем не в тему". Это нужно отлавливать, предлагать (именно предлагать, а не навязывать) свое решение, обсуждать варианты и т.п.
M> 2. Решение в более/менее предлагаемом варианте. Тут просто нужно следить за скоростью реализации.
M> 3. Предложен вариант лучше, чем предполагался. Здесь скорость реализации будет даже быстрее, чем изначально планировалось.
M> 4. Предложен "оригинальный" вариант и сложно сказать, что выйдет. Здесь нужно экспериментировать, смотреть. И нужно сам процесс принятия решения организовывать.
M>В общем, не все так просто. Тот же scrum предполагаемое решение согласует на scrum-meeting'е и со сроками будет определенность.

Согласен, с юниорами не так все просто. О них и речь. Как скрам-митинг решит эту определенность? Те же опытные программисты за них разобьют все на подзадачи и оценят с учетом юниорского опыта, со скрамом или без.

M>А еще производительность плавает по мере набора опыта и т.п. И переход от "пишем в три итерации под надзором" до "оно работает и есть интересные решения". Плавает она и по внешним причинам (как и у других членов команды). И уж тем более плохо с оценкой новых задач для Junior'а. Может, он не делал ничего ни разу, но у него отличная теоретическая подготовка и задачу он сделает быстро. Или, наоборот, не получается у него какая-то одна тема (даже у опытных разработчиков есть слабые и сильные места).

M>В общем, с юниорами как раз получается "agile в миниатюре" с планированием в рамках "небольшой командной итерации" и этапами "1-2 дня", контролем, принятием при необходимости мер и т.п. И ни в коем случае не "классическое планирование".

SD>>>Если бы члены команды уже имели бы опыт скрам — все выяснилось бы через 2-3 месяца.

G>>Все же мне интересно, что вы говорите заказчику? "Ну мы начнем делать то, что вы хотите, а через 3 месяца мы вам назовем сроки и цену. Подождите чутка, у нас опытная команда, не ищити другую фирму, плиииз"

M>Нормальному заказчику в общих чертах объясняется процесс. То, что через 2 недели будет минимальный набор функциональности, через 1 месяц функциональности будет чуть больше и т.д. И при этом по завершении двухнедельной итерации можно будет покрутить продукт, спланировать его дальнейшее развитие и т.п. Можно также рассказать о типичных сложностях планирования "fixed cost", незавершающихся проектах и т.п. Ну да, заказчику придется поднапрячься и понять, что же будет происходить. Но зато если он разберется, получит возможность управлять затратами, возможность закрыть проект (если он не выгоден) и т.п. Это нормальное управление рисками. А вот "отдать проект реализовывать на три месяца без вестей с фронта" можно только если за просрочку/недостаточную функциональнось предусмотрена хорошая неустройка. Но ведь не пойдут на это компании, разрабатывающие по классике.

Красиво пишете. Вы если дом строите, после 2х недель можете заказчику квартиру показать, в которую можно заезжать и жить? А шахту для лифта когда делать будете и на сколько этажей? А платить он будет как, после каждой готовой "квартиры", по чястям?

V_S>По-видимому, это как раз и зависит от личного опыта. У меня это самый личный опыт — положительный: проекты были сданы в срок и уложились в бюджет. (Да, менеджились они — "традиционно", а вот объемом функционала можно было управлять....)

Могли ли вы в любой момент сказать "а если добавим вот это, то проект завершится на 2 недели позже"? Могли ли ответить на вопрос "мы у вас Васю заберем на месяц, починить соседям проект" — как это отразится на вас?
Я тоже участвовал в "традиционных проектах без фиксации функционала" — и завершались они все примерно так: волевым решением объявлялся feature freeze, потом code freeze, и потом релизили что получилось. Между упомянутым решением "релизим что есть" и собственно релизом проходило более 4х месяцев (на самом деле, три из них — до беты, и еще месяц на то, чтобы дырки беты кое-как заткнуть, получился RC, который уже в некотором роде релиз).
Только все это было не по понятному и осмысленному плану, а по факту: "все, больше времени нет, релизим что можем".

Как я уже упоминал, скрам и вообще любой agile не даст немедленного ускорения работы команды (хотя следует признать, что по мере накопления опыта положительный эффект будет проявляться). Качество кода (в т.ч. покрытие тестами — без них признать фичу сделанной не выйдет, а значит, она не будет принята как "сделано" в конце итерации) конкретно в нашем случае улучшилось, но если команда и ранее практиковата TDD или 100% test coverage — ничего не изменится.

Основная выгода в прозрачности и предсказуемости.

G>Я так и не понял, что же тут неприятного если на то есть обьяснение уважительной причины?! У ваших людей проблемы с психикой или они настолько не адекватны, что не могут обьяснить причины?

Прекратите паясничать. Если вы продолжите это делать, я просто перестану вам отвечать.

G>Да откуда вы взяли эту чушь? Такое впечатление, что вы со школьной скамьи попали на скрам тренинг и потом в скрам команду, где и по сей день.

Если бы было так, как вы предположили, откуда бы у меня было знание того, как это происходит в традиционном варианте? У меня было семь лет коммерческого опыта до внедрения скрам. И еще три — после ухода из той компании. Итого, более 10 лет вне скрам. Кстати, ни одной "вступительной лекции по скрам" я не посетил. Моё понимание предмета идет исключительно из практики.

G>Как в скраме руководство может оценить скорость команды если она величина постоянная? Кстати, руководство вы имеете ввиду: скрам-мастер, продакт оунер?

Под руководством в данном случае понимается бенефициар. Заказчик ли, или владелец софтостроительной компании. В общем, тот, кто заинтересован в реализации продукта. Это внешний по отношению к команде персонаж. Руководство может быть либо удовлетворено скоростью команды (независимо от того, "по чайной ложке в год" это или Windows 8 за полгода), а может быть недовольно. Поскольку вся статистика скрам-команды доступна публично, руководству не требуются всяческие задушевные беседы и прочие инструменты выснения, "а чего все так медленно". Если команда тупо саботирует проект, не надо быть семи пядей во лбу, чтобы об этом догадаться. И как раз скрам позволит выявить сие на ранней стадии — буквально за несколько итераций. Тогда как с традиционным вариантом можно хоть целый год "устаканивать архитектуру" и не иметь работающего продукта вообще.

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

Это вам в ветку про метрики. "Сколько строчек в день нужно коммититить, чтобы стать самым крутым программистом". Ни одна из известных мне agile-методик не оценивает производительность команды по количеству строк кода. Потому как методики направлены на доставку функционала (value) заказчику.

G>Почему через пол-года. Есть модули которые надо сдавать в определенные сроки, тестировать, сдавать на ревью, в QA ит.д. Отличие от скрама только в том что сроки задач более логичные и варьируются в разумных пределах в зависимости от сложности задачи, а не фиксированные искусственно-раскроенные на равные части итерации как в скраме.

И это важнейшее свойство скрам — ритмичность итераций! Ключевое, не побоюсь этого слова. Каждую итерацию есть готовый продукт (ну, хорошо, будем честными — обычно для релиза нужно одну или две стабилизационные итерации). Такого, чтобы проект был полностью разобран и на приведение его в релизный вид нужно было полгода — в скрам ситуация невозможная по определению. В традиционном варианте я видел это сплошь и рядом. Вы, само собой, возразите, мол, "плохой менеджмент". Может, и плохой, — не мне оценивать. Но такую ситуацию я встречал во всех компаниях. От маленьких стартапов до интернациональных монстров.

G>Я понял основы и детали, и вижу его преимущества и кучу недостатков. Может это вам надо попробовать снять розовые очки?

Превосходно. Тогда, может, это и следует обсудить? Называйте, с вашей точки зрения, недостатки Agile и scrum. Я, в свою очередь, назову свои соображения на эту тему. Серебряной пули не существует, я это знаю. У скрам есть проблемы — в первую очередь, сложность его реализации: все простые вещи очень сложно реализовать. У него есть своя область применимости.
Но вы обо всем этом не пишете, ограничиваясь общими словами "в традиционном варианте у меня все работает, а вы неправы". Заметьте, вы даже конкретные примеры не приводите. Поэтому у меня и возникают сомнения в ваших словах.

G>предсказуемости и завершаемости — спасибо, посмеялся.

Если вы не смогли этого добиться за несколько лет скрам — это 100% показатель СкрамНо.

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

Задам отвлеченный вопрос. Вы когда-нибудь играли в командные игры? Футбол, баскетбол, волейбол? Да хотя бы в какие-нибудь современные компьютерные онлайн-игры. В конце концов, в "зарницах" участвовали лет 20 назад? Неужели вас никогда не захватывал командный дух и азарт? Сочувствую. Вы действительно многое теряете в жизни.

G>Целью любых методик является производство продукта. Целью любого чека, кто участвует в разработке продукта есть персональный профит. У каждого он разный, но в основном: деньги или слава. (с) КО

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

G>начальника? ну скажем так: более опытного, старшего программиста, который делал подобное уже раньше и к тому же знает квалификацию юниора, которому предстоит занятся данной задачей первый раз в жизни.

А как же "индивидуальность разработчика"? Вы не ответили на мой вопрос: хотите ли вы, чтобы какой-то Вася за вас оценивал, сколько вам делать тот или иной модуль? Вы, кстати, Васю не считаете опытным и старшим программистом — вы его по возрасту старше, и опыта у вас больше, и вообще вы его недолюбливаете за то, что он занимается подхалимством.

G>Опять страшилки с вводной части курса по скраму. Узнаю

Видите, как интересно получается — я не был ни на курсе скрам, ни на его вводной части, а "страшилки" откуда-то знаю, причем в красках, деталях, и исключительно реалистично. Удивительная осведомлённость, вы не находите?

G>Все же мне интересно, что вы говорите заказчику? "Ну мы начнем делать то, что вы хотите, а через 3 месяца мы вам назовем сроки и цену. Подождите чутка, у нас опытная команда, не ищити другую фирму, плиииз"

А что говорите вы? Просто оценки от балды? Или все-таки делаете какие-то формальные ТЗ, согласования и т.п.? Ведь это тоже занимает значительное время. Вам я тоже рекомедую погуглить по словам cone of uncertainty.

G> Где контроль? Скрам не содержит сосотяние проекта в тумане?

Контроль — каждую итерацию. Для начинающих команд раз в две недели, потом кто-то переходит на 3 или 4, зависит от команды.

Само собой, вы можете возразить — "все это можно реализовать и без скрам".

Можно.

Хотите очередной вариант СкрамНо — пожалуйста. Применяйте. Просто не жалуйтесь потом, что "оно не работает". Вас предупреждали.

Знаете, пожалуй, вы выявили один из важных недостатков скрам (и вообще agile). Он заключается в том, что каждый называет какой-то свой процесс этим словом, и потом, когда выясняется, что процесс плохо работает, начинаются обвинения скрам. Видимо, это и вызвало волну сертификаций.

G>Красиво пишете. Вы если дом строите, после 2х недель можете заказчику квартиру показать, в которую можно заезжать и жить? А шахту для лифта когда делать будете и на сколько этажей? А платить он будет как, после каждой готовой "квартиры", по чястям?

Почти так. После 2х недель заказчику дается квартира. Без лифта, по лестницам надо топать. Шахта — открытая. Крыша — времянка. Если заказчик скажет "все, баста, мне 10 этажей уже не надо, давайте только два" — за следующую итерацию крыша перекрывается на production grade, устанавливается лифт нужной конструкции, дом сдается.

По вопросам оплаты — читайте все ту же Agile Estimating and Planning, там ажно целая глава на тему финансовой приоретизации. Краткий смысл — заказчик может платить хоть за каждый реализованный сценарий.

Для сравнения, как это выглядит в традиционном варианте — договорились на 10-этажку, полгода что-то там делали, заказчику показывают только чертежи. В смысле, планы и ни о чем не говорящие названия модулей, каждый из которых на треть уже написан. Ну, в смете показывают — десять панелей, 30 тонн бетона, 10 тонн металлоконструкций...

Здравствуйте, SkyDance, Вы писали:

G>>Красиво пишете. Вы если дом строите, после 2х недель можете заказчику квартиру показать, в которую можно заезжать и жить? А шахту для лифта когда делать будете и на сколько этажей? А платить он будет как, после каждой готовой "квартиры", по чястям?

SD>Почти так. После 2х недель заказчику дается квартира. Без лифта, по лестницам надо топать. Шахта — открытая. Крыша — времянка. Если заказчик скажет "все, баста, мне 10 этажей уже не надо, давайте только два" — за следующую итерацию крыша перекрывается на production grade, устанавливается лифт нужной конструкции, дом сдается.


А вот если заказчику нужно 10 этажей, то вдруг выясняется на 20 итерации скрама , что лифт работает только в демо -режиме и ездит только на второй этаж. А чтобы сделать нормальную крышу, надо снимать временную, разобрать весь дом и собрать заново .

S>А вот если заказчику нужно 10 этажей, то вдруг выясняется на 20 итерации скрама , что лифт работает только в демо -режиме и ездит только на второй этаж.

Т.е. работа шла по СкрамНо, выходит.
Поскольку в scrum by the book при достройке каждого очередного этажа лифт переносят на этаж выше.

S>А чтобы сделать нормальную крышу, надо снимать временную, разобрать весь дом и собрать заново

Как вы прекрасно понимаете, сия ситуация отнюдь не специфична для Agile или SCRUM.

Здравствуйте, goondick, Вы писали:

G>Здравствуйте, vpedak, Вы писали:
G>Квадратики в МS Project? Я думаю на этом можно завершить дискуссию...

hint: есть такая диаграмма в project, называется Диаграмма Ганта. А вам домашнее задание найти в ней квадратики...

G>Могут делатся, но зачем?

ну т.е. fixed price проекты нам не нужны?

G>Т.е. скрам учитывает человеческий фактор и одновременно 100% вываливание из сроков? Я вас не понимаю.

Вот именно что не понимаете, прочитай еще раз мои сообщение и убедитесь что я не писал что из-за скрам все проекты вываливаются по срокам.

G>"опытный" менеджер? нет, я говорил о тимлиде, старшем программисте и ему подобных.

у них что с телепатией лучше? НЕТ одного такого в команде кто правильно за всех оценит сроки. Весь смысл что вся команда согласится при spring planing с объемом работ и сроками. И здесь есть элемент мотивации. Раз подписались — надо делать (проверено это работает)

А когда мне сверху сроки спускают (которые обычно сильно завышены, так как оценщик он же опытный у нас) то я ведь так и сделаю. Могу и за 3 дня, а могу и за 5 (хотя там если нормально попахать то и за 2 дня справишься).

G>Полгода идет оценка производительности, потом узнают сроки

Да, это так. Потому что это реальная оценка. Она важнее для бизнеса, чем какой-то проект сделанный в MS Project который и 50% реальности не показывает.
Если вам важен сам продукт который делается то вам и оценка реальная будет важна.

V>>Но это работает только тогда когда и заказчик и исполнитель заинтересованы в результате. А не просто заинтересованы в том, чтобы какую-то хрень сдали вовремя (неважно насколько она получилась хороша и полезна).

G>А что, бывают не заинтересованны?

V>>Ну а так как в большинстве случаев всем пофиг на реальный результат — то и agile редко где реально нужен получается.

G>Что за бред?

Добро пожаловать в реальный мир. В нашем реальном мире в любой организации существует очень много внутренней политики и у большинства работников компании личные цели очень далеки от целей компании (если даже варианты когда цели эти противоположны).


Вячеслав Педак

Здравствуйте, SkyDance, Вы писали:


SD>У меня было семь лет коммерческого опыта до внедрения скрам. И еще три — после ухода из той компании. Итого, более 10 лет вне скрам. Кстати, ни одной "вступительной лекции по скрам" я не посетил. Моё понимание предмета идет исключительно из практики.

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

SD>Под руководством в данном случае понимается бенефициар. Заказчик ли, или владелец софтостроительной компании. В общем, тот, кто заинтересован в реализации продукта. Это внешний по отношению к команде персонаж. Руководство может быть либо удовлетворено скоростью команды (независимо от того "по чайной ложке в год" это или Windows 8 за полгода), а может быть недовольно. Поскольку вся статистика скрам-команды доступна публично

а что, тимлид скрывает косяки от PMa, PM от начальства?

SD>..руководству не требуются всяческие задушевные беседы и прочие инструменты выснения, "а чего все так медленно". Если команда тупо саботирует проект, не надо быть семи пядей во лбу, чтобы об этом догадаться. И как раз скрам позволит выявить сие на ранней стадии — буквально за несколько итераций. Тогда как с традиционным вариантом можно хоть целый год "устаканивать архитектуру" и не иметь работающего продукта вообще.

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


SD>И это важнейшее свойство скрам — ритмичность итераций! Ключевое, не побоюсь этого слова. Каждую итерацию есть готовый продукт (ну, хорошо, будем честными — обычно для релиза нужно одну или две стабилизационные итерации).

Это одно из самых абсурдных принципов разработки продукта в принципе и визитная карточка нелепости скрама для большинства проектов.


SD>Превосходно. Тогда, может, это и следует обсудить? Называйте, с вашей точки зрения, недостатки Agile и scrum. Я, в свою очередь, назову свои соображения на эту тему.

недостатки:
1. ритмичность итераций. Следствие: архитектурные проблемы
2. готовый продукт после каждой итерации. Следствие: никому не нужный абсурд, занимающий дополнительное время и архитектурные проблемы
3. самоорганизация. Следствие: "лебедь, рак и щюка"
4. общее владение кодом и общая ответственность за код. Следствие: знаю обо всем помаленьку — не знаю ничего.
5. отсутствие распределения разработки функционала в зависимости от квалификации разработчика. Следствие: снижение качества и/или скорости разработки


SD>Задам отвлеченный вопрос. Вы когда-нибудь играли в командные игры? Футбол, баскетбол, волейбол? Да хотя бы в какие-нибудь современные компьютерные онлайн-игры. В конце концов, в "зарницах" участвовали лет 20 назад? Неужели вас никогда не захватывал командный дух и азарт?

В традиционной разработке тоже команда и командный дух, только у всех немного разные роли. Как футболе: тренер, капитан, нападающий, защитник, полизащитник, вратарь. Онлайн-игры: батлфилд: командир, скуадлидер, пулеметчик, медик, сапер, снайпер...
В скраме же команда без главного и ролей.


SD>люди, которые заинтересованы исключительно в продлении сроков и увеличении бюджетов проекта — им прозрачные методики невыгодны и скрам не получит поддержку.

люди в любом случае заинтересованы в наискорейшем завершении проекта, хотя бы даже потому чтобы фирма получила новый контракт, начала новый проект и не обанкротилась и не пришлось искать новую работу. Заинтересованность в продлении сроков это второстепенно, в следствии отставания от плана, и никак не влечет за собой саботирование работы. У вас странная причино-следственная связь о данной ситуации.

G>>начальника? ну скажем так: более опытного, старшего программиста, который делал подобное уже раньше и к тому же знает квалификацию юниора, которому предстоит занятся данной задачей первый раз в жизни.

SD>А как же "индивидуальность разработчика"? Вы не ответили на мой вопрос: хотите ли вы, чтобы какой-то Вася за вас оценивал, сколько вам делать тот или иной модуль? Вы, кстати, Васю не считаете опытным и старшим программистом — вы его по возрасту старше, и опыта у вас больше, и вообще вы его недолюбливаете за то, что он занимается подхалимством.

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

Здравствуйте, goondick, Вы писали:

G>это еще более удивляет. Обычно с годами приходит понимание как грамотно организовать процесс с участием людей разной квалификации, а за скрам иде?и в основном выступает молодежь (стадный инстинкт перед непонятным, рапределение ответственности на всех).

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

SD>>Под руководством в данном случае понимается бенефициар. Заказчик ли, или владелец софтостроительной компании. В общем, тот, кто заинтересован в реализации продукта. Это внешний по отношению к команде персонаж. Руководство может быть либо удовлетворено скоростью команды (независимо от того "по чайной ложке в год" это или Windows 8 за полгода), а может быть недовольно. Поскольку вся статистика скрам-команды доступна публично

G>а что, тимлид скрывает косяки от PMa, PM от начальства?

а что? такого не бывает?

G>"задушевные беседы", "саботирует проект", "устаканивать архитектуру", "не иметь работающего продукта вообще". — ну если это ваше представление ситуации в традиционной разработки, тогда я уже не знаю что и сказать, вас похоже кто-то "изнасиловал" по молодости плохой традиционной разработкой какого-то никому не нужного говнопродукта.

в разработке софта ОЧЕНЬ много именно взаимодействия людей, а не только технологий. Почитайте на досуге — http://www.maxkir.com/sd/people_as_nonlinearRUS.htm
Похоже это вы — "слаще морковки ничего не видели"

SD>>И это важнейшее свойство скрам — ритмичность итераций! Ключевое, не побоюсь этого слова. Каждую итерацию есть готовый продукт (ну, хорошо, будем честными — обычно для релиза нужно одну или две стабилизационные итерации).

G>Это одно из самых абсурдных принципов разработки продукта в принципе и визитная карточка нелепости скрама для большинства проектов.

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


G>недостатки:
G>1. ритмичность итераций. Следствие: архитектурные проблемы

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

G>2. готовый продукт после каждой итерации. Следствие: никому не нужный абсурд, занимающий дополнительное время и архитектурные проблемы

ну да, никому не нужный абсурд (кроме заказчика который за все это платит и самой команжы которая начинает получать feedback сразу)

G>3. самоорганизация. Следствие: "лебедь, рак и щюка"

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

hint: самоорганизация != анархия

G>4. общее владение кодом и общая ответственность за код. Следствие: знаю обо всем помаленьку — не знаю ничего.

ну вот у нас продукт сейчас выходит версии 9.5. и никого уже нету кто его начинал. И что? Мы вынуждены иметь общую ответственность за код. Не умерли еще.

G>5. отсутствие распределения разработки функционала в зависимости от квалификации разработчика. Следствие: снижение качества и/или скорости разработки

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

G>В скраме же команда без главного и ролей.
Есть в скраме роль скрам мастера который "следит за правилами игры". И роли есть внутри команды, просто у них незвания не "протокольные". Вон например Вася, он спец по базам, на него обычно все сложные задачи по базам валим и к нему за советом ходим. А вот Петя, тот самый старый работник на поекте, он больше всех про код знает и т.д.

Да, тут нету официального "архитектора" который сидит тут давно и его поэтому никто выгнать не может. Он уже нифига не понимает в новых технологиях, но ведь он хороший, давно работает, пусть сидит. Вам такое надо?

G>люди в любом случае заинтересованы в наискорейшем завершении проекта, хотя бы даже потому чтобы фирма получила новый контракт, начала новый проект и не обанкротилась и не пришлось искать новую работу. Заинтересованность в продлении сроков это второстепенно, в следствии отставания от плана, и никак не влечет за собой саботирование работы. У вас странная причино-следственная связь о данной ситуации.

Снимите свой "розовые очки" и поймите наконец что от конкретного проекта может вообще нифига не зависеть и вообще бывают проекты которые специально делаеют чтобы завалить и т.д. Если мой текущий работодатель обанкротится — то поверьте это будет совсем не от того что я код плохо написал... Скорее топ менеджеры накосячат (или еще хуже если "сольют" компанию, как например было с Borland)


Вячеслав Педак

Здравствуйте, vpedak, Вы писали:

V>Здравствуйте, goondick, Вы писали:

G>>это еще более удивляет. Обычно с годами приходит понимание как грамотно организовать процесс с участием людей разной квалификации, а за скрам иде?и в основном выступает молодежь (стадный инстинкт перед непонятным, рапределение ответственности на всех).

V>Ну вот вам и объясняют что с годами поняли насколько скрам бывает хорош. А вы не понимаете... Меня тоже это удивляет

SD>>>Под руководством в данном случае понимается бенефициар. Заказчик ли, или владелец софтостроительной компании. В общем, тот, кто заинтересован в реализации продукта. Это внешний по отношению к команде персонаж. Руководство может быть либо удовлетворено скоростью команды (независимо от того "по чайной ложке в год" это или Windows 8 за полгода), а может быть недовольно. Поскольку вся статистика скрам-команды доступна публично

G>>а что, тимлид скрывает косяки от PMa, PM от начальства?

V>а что? такого не бывает?

G>>"задушевные беседы", "саботирует проект", "устаканивать архитектуру", "не иметь работающего продукта вообще". — ну если это ваше представление ситуации в традиционной разработки, тогда я уже не знаю что и сказать, вас похоже кто-то "изнасиловал" по молодости плохой традиционной разработкой какого-то никому не нужного говнопродукта.

V>в разработке софта ОЧЕНЬ много именно взаимодействия людей, а не только технологий. Почитайте на досуге — http://www.maxkir.com/sd/people_as_nonlinearRUS.htm
V>Похоже это вы — "слаще морковки ничего не видели"

SD>>>И это важнейшее свойство скрам — ритмичность итераций! Ключевое, не побоюсь этого слова. Каждую итерацию есть готовый продукт (ну, хорошо, будем честными — обычно для релиза нужно одну или две стабилизационные итерации).

G>>Это одно из самых абсурдных принципов разработки продукта в принципе и визитная карточка нелепости скрама для большинства проектов.

V>ну если вы не можете после каждого спринта отгружать версию заказчику — то это не значит что другие не могут


G>>недостатки:
G>>1. ритмичность итераций. Следствие: архитектурные проблемы

V>У вас логика — супер. Если представить, что каждый кто умер ел хоть раз в жизни огурцы, то можно сделать вывод что огурцы это отрава... Хоть намекните почему итерации вызывают архитектурные проблемы...

G>>2. готовый продукт после каждой итерации. Следствие: никому не нужный абсурд, занимающий дополнительное время и архитектурные проблемы

V>ну да, никому не нужный абсурд (кроме заказчика который за все это платит и самой команжы которая начинает получать feedback сразу)

G>>3. самоорганизация. Следствие: "лебедь, рак и щюка"

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

V>hint: самоорганизация != анархия

G>>4. общее владение кодом и общая ответственность за код. Следствие: знаю обо всем помаленьку — не знаю ничего.

V>ну вот у нас продукт сейчас выходит версии 9.5. и никого уже нету кто его начинал. И что? Мы вынуждены иметь общую ответственность за код. Не умерли еще.

G>>5. отсутствие распределения разработки функционала в зависимости от квалификации разработчика. Следствие: снижение качества и/или скорости разработки

V>это почему? Когда человек закончил свою задачу он берет задачу из пула всех задач не сам по себе, а обычно на скрам митинге. Там все и решают какую задачу ему лучше взять исходя из его опыта и знаний.

G>>В скраме же команда без главного и ролей.
V>Есть в скраме роль скрам мастера который "следит за правилами игры". И роли есть внутри команды, просто у них незвания не "протокольные". Вон например Вася, он спец по базам, на него обычно все сложные задачи по базам валим и к нему за советом ходим. А вот Петя, тот самый старый работник на поекте, он больше всех про код знает и т.д.

V>Да, тут нету официального "архитектора" который сидит тут давно и его поэтому никто выгнать не может. Он уже нифига не понимает в новых технологиях, но ведь он хороший, давно работает, пусть сидит. Вам такое надо?

G>>люди в любом случае заинтересованы в наискорейшем завершении проекта, хотя бы даже потому чтобы фирма получила новый контракт, начала новый проект и не обанкротилась и не пришлось искать новую работу. Заинтересованность в продлении сроков это второстепенно, в следствии отставания от плана, и никак не влечет за собой саботирование работы. У вас странная причино-следственная связь о данной ситуации.

V>Снимите свой "розовые очки" и поймите наконец что от конкретного проекта может вообще нифига не зависеть и вообще бывают проекты которые специально делаеют чтобы завалить и т.д. Если мой текущий работодатель обанкротится — то поверьте это будет совсем не от того что я код плохо написал... Скорее топ менеджеры накосячат (или еще хуже если "сольют" компанию, как например было с Borland)


V>Вячеслав Педак

Слава, я устал отвечать на ваш феерический бред в оправдание скрама. Бесконечная тема может быть пересена в "священные войны". Адиос.

Здравствуйте, goondick, Вы писали:

G>Слава, я устал отвечать на ваш феерический бред в оправдание скрама. Бесконечная тема может быть пересена в "священные войны". Адиос.

Я хоть пытаюсь аргументировать свою позицию. Привожу ссылки на мнение уважаемых в индустрии людей...

А в ответ только — бред, какие-то "сферические" архитектурные проблемы.

Грустно...


Вячеслав Педак

Здравствуйте, vpedak, Вы писали:

V>Здравствуйте, goondick, Вы писали:

G>>Слава, я устал отвечать на ваш феерический бред в оправдание скрама. Бесконечная тема может быть пересена в "священные войны". Адиос.

V>Я хоть пытаюсь аргументировать свою позицию. Привожу ссылки на мнение уважаемых в индустрии людей...

V>А в ответ только — бред, какие-то "сферические" архитектурные проблемы.

V>Грустно...


V>Вячеслав Педак

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

Здравствуйте, goondick, Вы писали:

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

О! Потрясающе. А при чем здесь скрам то? Он ведь по-другому работает. Там же нет разбиения на двухнедельные итерации с самого начала. Зато на каждой итерации выделяется несколько задач (от оставшегося куска) и реализуются. Заодно по факту выполнения начальных задач корректируется текущая скорость и можно примерно оценить, сколько еще осталось пилить оставшуюся часть. Есть еще очень важный момент. Нужно быть честным и вместо попытки "на костылях" успеть в двухнедельный срок признавать, что "не успели". Это приведет к переносу реализации фичи на следующую итерацию, коррекции velocity и общих "прогнозов". Но никаких костылей, полностью рабочий продукт (да, в меньших объемах, чем выбрали на итерацию, но все равно рабочий). И в коде остаются не костыли, а предусмотренная архитектурой реализация функциональности.

Кстати, не говорите, что в scrum'е нет архитектуры. Высокоуровневая архитектура есть. И делается она на самом деле тогда же, когда и в BDUF'е (Big Design Upfront) — на этапе анализа задачи. Это выполняется до того, как вы сказали заказчику "мы будем делать проект три месяца" и получили какие-то деньги. Просто потому, что иначе сложно получить хоть какие-то правдоподобные сроки. А вот уже детализация дизайна выполняется в разное время. В Agile — по мере необходимости. Во BDUF'е — сразу после начала проекта, со всеми вытекающими отсюда рисками (она может не понадобиться, могут потребоваться переделки и т.п.).

P.S. Я немного обобщу ваше утверждение. Нельзя разделить любой проект на части и сдавать полностью работающий функционал фиксированные промежутки времени. Или будет страдать качество, или будет "заметаться мусор в уголок" и ставиться костылики, которые всплывут через несколько частей. В общем, водопад и прочие подходы с априорным планированием не работают. Agile не пытается делать подробное априорное планирование. Большая часть планирования/приоретизации и т.п. выполняется в процессе работы.

Здравствуйте, hrensgory, Вы писали:

H>Мне неясно как это уменьшает вероятность того, что "ближе к концу
H>проекта начинаются постоянные рефакторинги, скорость и качество падают
H>потому что первые итерации говнокодили в основном для демо". Ну заменим
H>слово "демо" на "полноценный программный продукт с урезанной (может быть
H>— очень сильно) функциональностью."
Не, не то. Нужно слово "говнокодили" убирать. Если "говнокодили", это было СкрамНо. Нельзя ухудшать качество с целью достижения сроков. Вот "вылететь" за срок и перенести задачу на следующую итерацию — можно. Это скажется на velocity и дальнейших оценках. Но говнокода не будет. Ага, честным быть тяжело. Но без этого scrum не будет работать.

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

Сама проблема "ближе к концу проекта начинаются рефакторинги" может существовать и при построении плана работ до начала проекта. Там те же рефакторинги будут возникать на этапе интеграции. И проблемы с говнокодом будут те же самые — он будет появляться, чтобы сдать модуль в срок. Скрам же не ставит задачу "сдать всю функциональность в срок", поэтому и такого класса проблем просто нет. Т.е. проблему "потребуются рефакторинги" scrum тоже не решает (здесь он не лучше, и не хуже планирования до начала работ). Но вот шансы обнаружить высокоуровневые проблемы (ошибки в требованиях, ошибки в архитектуре, проблемы с интеграцией модулей) можно раньше, так как образец программы для тестирования появляется раньше.

H>Речь про стоимость добавления фич, превращающих "то, что вообще можно
H>где-нибудь развернуть" в то, "что имеет для заказчика бизнес-смысл". Или
H>вы хотите сказать, что этого в среднем можно достичь за месяц-полтора?
H>SkyDance тут рассказывал что-то про полгода что ли, после которого
H>решили, что пора завязывать — ничего не выходит.

А там и до "рефакторингов" скорее всего дело не дошло. Я так подозреваю, что они получили честный velocity на разработке и решили, что продолжать смысла нет. Это совсем не из-за подпорок. Это из-за того, что с нормальным качеством они получили объективную скорость и команда не успевала. А вот при "гонке за планом" было бы готово уже "90% модулей", но вот при интеграции и тестировании вылезла бы куча проблем. И не важно, был бы план двухнедельным (с целью его догнать!) или с неравными интервалами для разных модулей.

Здравствуйте, goondick, Вы писали:

G>>>Представьте на минуточку разбить задачу на подзадачи, оценить сроки выполнения подзадач. По мере реального выполнения подзадач корректировать сроки или ресурсы проекта.

M>>А возможные проблемы при выполнении задач оценить? Например, не сработает по каким-то критериям подход, который предполагался для решения задач.

G>И? Скрам как эти проблемы решает? Не срабатывает подход решения задачи, вместо 1 "енота"SP задача будет внезапно весить 16 "енотов" SP. Отлично, все что посчитали ранее по велосити и SP можно считать недействительным. В чем разница эпического фейла с менежерской точки зрения на эту проблему?

Вероятность фейла ниже. В отличие одного (ладно, двух) разработчиков, оценивающих фичу, в SCRUM'е ее оценивает вся команда (которая обычно побольше будет). Причем при планировании до проекта тимлид может предполагать, что задачу будет делать Вася, а ее на самом деле будет делать Петя. Время на передачу знаний и т.п. там не учтено. На scrum-митинге же в процессе выработки согласованной оценки Пете придется познакомиться с задачей, вариантами решения (да хоть у Васи спросить) и дать свою оценку.

Да и какая проблема со SCRUM'ом? Оценку проекта мы не давали (он не оперирует со сроками реализации фичей, только с размером итерации). Да, чуть поплыла velocity. Да, фича улетела на следующую итерацию. Да, получили продукт без фичи А на итерации. Бывает, рабочий процесс. Если фейл однократный, velocity подкорректируется обратно. Если подобные фейлы частые — так и останется низкой, что окажется полезным для оценки перспектив всего проекта.


G>Именно демонстрацией какой-либо фичи (натянутой за уши как готовой) заказчик всегда и ограничивался на практике.
Это от заказчиков зависит. Конечно, если заказчик не хочет убедиться, что его поняли правильно и делают то, что ему нужно, ему будет достаточно демо. Такую необходимость нужно объяснять, заказчик про это может даже не пдозревать. Но если после объяснения он все равно не хочет тестировать, вероятно, программа ему вообще не нужна.

Да, что касается практики. Это вы в scrum пробовали? Или это практика с предварительным планированием? В последнем случае оно обычно ограничивается демонстрацией фичи потому, что заказчику программу не дают. Ага, та самая "демо, собранная на подпорках", которой вы боитесь в scrum'е. И будет видно, что программа ни на что, кроме демо, не способна . А в scrum'е такой номер не пройдет.

G>1. Фича очень часто зависит от другой, которая будет готова в след. итерации.
Ух ты! Почему тогда она попала в текущую итерацию? Сначала должна была идти фича, которая будет в следующей итерации. В конце концов, она "важнее" (без нее не будет двух фичей, а с ней будет по крайней мере одна). А вот для предварительного планирования такая ситуация как раз характерна. В плане фичи стояли "параллельно" и одна из них задержалась. Поэтому и интеграция задержалась.

G>2. Даже полнофункциональная фича часто теряет смысл в практическом применении в технологическом процессе, пока не будет готова большая часть продукта.
Ну не применяйте пока в техпроцессе. Хотя бы проверьте, что фича делает то, что нужно. Можно будет на следующей итерации устранить какие-то недоделки, недопонимания и т.п.

G>3. Продукт после нескольких итераций используется пару людьми из тех.отдела в рамках тестирования, теми кто ответственный за финальное внедрение. Много они его натестируют в отрыве от "реальной жизни"? Даже если условия позволяют подключить к процессу тестирования всю фирму, у тех.персонала просто физически не будет возможности к дистибуции версий, обучения и сбора багрепортов каждые 3 недели.
Ну опять возвращаемся к тому, что заказчику продукт не нужен. Здесь никаких бонусов от скрама не будет. И будут все те же проблемы с "полгода на внедрение" потому что где-то что-то при составлении требований было понято не так, появились новые необходимые доделки и т.п.

G>Сладкая утопия из книжек по скраму.ки сдохнут под тяжестью проекта, почти никто расстраиваться не будет (ну да, разработчики во главе с менеджером меньше денег получат).
Не читал книжек по скраму. Из-за скрама в данном случае проект не сдохнет. Он сдохнет из-за завышенных ожиданий до начала проекта. И сдохнет он быстрее, чем при "предварительном планировании". Что хорошо для заказчика (он потратил меньше денег). Да и для команды неплохо — они пойдут к другому заказчику. Какая проблема то? Времени потратили меньше. Денег получили меньше, чем за выполненный проект. Но вот с fixed cost и penalty (за просрочку/качество) команда бы вылетела в два раза по срокам и тоже получила меньше денег, чем планировалось. Никаких проблем не вижу.

Здравствуйте, goondick, Вы писали:

G>Здравствуйте, maxkar, Вы писали:


M>>А как еще в традиционном менджменте вы будете решать проблему с изменяющимися сроками? Заболел у вас программист и модуль А не был сделан в срок. А через три месяца после начала проекта вышла библиотека, которая позволит не делать модуль Б, на который в будущем был выделен месяц.

G>Ну вот вы сами и ответили, как одно компенсирует другое

Не компенсирует. Объясните мне, о какой прдесказуемости проекта идет речь в upfront planning? Вот у вас проект сначала стал отставать на один человекомесяц, а затем вдруг взял и опять вошел в норму. SCRUM не делает долгосрочных прогнозов. В краткосрочных же (на итерацию) станет видно, что за итерацию получится меньше функциональности, чем с полным составом команды. Он не дает иллюзий, что "все идет по плану и продукт будет в срок"

M>>И вопрос здесь даже не в сроках. Скрам (да и весь Agile) не пытается решить проблему определения сроков всего проекта. Но при этом позволяет оперативно реагировать на ситуацию и балансировать в рамках треугольника сроки/качество/функционал. Если все три параметра фиксированы, ничего нового и интересного (кроме раннего обнаружения невыполнения проекта) вы не получите.

G>"сроки/качество/функционал" — в чем разница баллансирования в других видах разработки?

А как вы собираетесь балансировать "сроки/качество/функционал", когда у вас все заранее распланировано? Ну да, на этапе интеграции вы начнете фичи резать. Потому что раньше вроде все было хорошо. А там уже проделано много лишней работы по данным фичам. Вот в примере выше, например, архитектор три дня потратил на детальный дизайн модуля Б, а потом библиотека вышла. В scrum модуль Б был бы сделан вместе с фичой, для которой требовался (и фича была бы доставлена пользователю раньше, чем при длительном планировании). Или библиотека вышла раньше и команда не потратила 3 человекодня на неиспользуемый дизайн.

M>>И все вышесказанное справедливо даже при том, что ТЗ фиксированное. А оно далеко не всегда фиксированное. Клиент, увидев начальный результат, может что-то изменить в проекте. Оказывается, какие-то задачи он может выполнить раньше/более простыми средствами, но при разработке ТЗ забыл совершенно про другую важную задачу.

G>Ну и в чем проблема? Захотел изменить функционал, вспомнил о важной фиче посередине проекта. Составляем изменение ТЗ, оговариваем сроки, деньги, едем дальше.
Дорого . Особенно дорого, когда какие-то фичи станут ненужны, а для них уже началась разработка. В scrum'е ими хотя бы могли попользоваться до тех пор, пока она не стала ненужна (или бы фича еще не была реализована). И самая большая проблема — заказчик рассказал совсем не то, что ему было нужно на самом деле. Это достаточно часто бывает. Для команды хорошо — лишние деньги (хотя переделывать психологически некомфортно), а вот для заказчика не очнеь.

M>>Вы забываете самый большой риск для "модульного" проекта — интеграция всех модулей в единое целое. Ее очень сложно планировать, там всплывают различные баги, допущенные на начальных этапах (что-то не оттестировали, что-то не заложили в спецификацию). В хронических случаях может доходить до того, что проще переделать какой-то модуль, чем интегрировать его в остальную систему. Гораздо более реалистичным и управляемым является не план в терминах "модулей", а в терминах "функциональность, реализуемая продуктом". Т.е. интеграция с самого начала. А это основной постулат вообще всех Agile. И наличие/отсутствие функциональности прекрасно видно (в отличие от модулей, которые по-отдельности работают хорошо, но нужно потратить кучу времени на их интеграцию). Ну а дальше добавляем различные стратегии оперативного управления и получаем различные варианты Agile.

G><...в терминах "модулей", а в терминах "функциональность, реализуемая продуктом". Т.е. интеграция с самого начала.> — кхм... что это? как это увязать с выдачей фичи народу в пользование каздые три недели?
А в чем проблема то? Ведь на итерацию же не ставится задача "разработать инфраструктуру доступа к базе данных" (которая ставится Пете и он ее месяц пилит). Ставится задача "вывести прайс из базы данных". В рамках этой задачи придется и часть инфраструктуры доступа к базе написать, и часть инфраструктуры рендеринга (отображения). Может быть, еще какие-то сервисы. Все слои/компоненты/модули/библиотеки интегрируются в одно приложение с самого своего появления.

M>>В общем, не все так просто. Тот же scrum предполагаемое решение согласует на scrum-meeting'е и со сроками будет определенность.

G>Согласен, с юниорами не так все просто. О них и речь. Как скрам-митинг решит эту определенность? Те же опытные программисты за них разобьют все на подзадачи и оценят с учетом юниорского опыта, со скрамом или без.

Так на митинге же и будет определенность. Там юниор должен согласиться с оценкой. И если он придумал что-то лучше, у него будет оценка ниже и вся команда вынуждена будет проверить решение (чтобы согласиться с этой оценкой). Заодно все и увидят другое разбиение, например. Или проблемы, которые новичок заметил а сеньоры из-за своего опыта на них внимания не обратили (это могут быть какие-нибудь внешне "незначительные" детали).


M>>Нормальному заказчику в общих чертах объясняется процесс. То, что через 2 недели будет минимальный набор функциональности, через 1 месяц функциональности будет чуть больше и т.д. И при этом по завершении двухнедельной итерации можно будет покрутить продукт, спланировать его дальнейшее развитие и т.п. Можно также рассказать о типичных сложностях планирования "fixed cost", незавершающихся проектах и т.п. Ну да, заказчику придется поднапрячься и понять, что же будет происходить. Но зато если он разберется, получит возможность управлять затратами, возможность закрыть проект (если он не выгоден) и т.п. Это нормальное управление рисками. А вот "отдать проект реализовывать на три месяца без вестей с фронта" можно только если за просрочку/недостаточную функциональнось предусмотрена хорошая неустройка. Но ведь не пойдут на это компании, разрабатывающие по классике.

G>Красиво пишете. Вы если дом строите, после 2х недель можете заказчику квартиру показать, в которую можно заезжать и жить? А шахту для лифта когда делать будете и на сколько этажей? А платить он будет как, после каждой готовой "квартиры", по чястям?
Да пускай, меня очень даже устроит! Я готов и по частям платить. Может, мне не нужна будет шахта лифта. Или после постройки пятого этажа я решу, что лифт нужен. И пусть строят лифт. Работающий лифт! После итерации у меня будет пятиэтажний дом с работающим лифтом. А не 10-этажная коробка без крыши, с нежилыми квартирами но зато с шахтой лифта.

И вообще аналогия неверная. Постройка дома — это construction. Аналог в IT — создание копий программы (цифровых, на дисках и т.п.). Аналогией создания ПО будет проектирование дома! И да, здесь тоже меня устроит сначала небольшой жилой дом (ну зачем мне 20-этажка без лифта). Затем к нему можно будет добавить лифт (с перепланировкой небольшой под шахту). Затем — еще несколько этажей (нужно проверять прочность дома и т.п.). А затем — по блэкджеку и бассейну на каждом этаже. Это лучше, чем если я закажу сразу 20-этажку со всеми возможностями, а мне через три месяца за мои же деньги скажут, что при существующих технологиях такое не строится или строится неоправданно дорого.

Здравствуйте, goondick, Вы писали:

G>Красиво пишете. Вы если дом строите, после 2х недель можете заказчику квартиру показать, в которую можно заезжать и жить? А шахту для лифта когда делать будете и на сколько этажей? А платить он будет как, после каждой готовой "квартиры", по чястям?

Кстати, а это ведь на самом деле очень хороший вариант. Я бы с удовольствием оплачивал строительство квартиры "по частям". Часть — после проекта. Часть — после рытья котлована. Часть — после постройки фундамента. Часть — после первого этажа. Часть — после второго и т.д. Ну и с возможностью решать — строить дальше, прекратить. Поставить лифты попроще/посложнее, ремонт разный у квартир сделать, разную планировку этажей (разбивку на квартиры) и т.п. Проблемы перераспределения квартир при завершении строительства пока не касаемся. Это же очень прозрачный вариант с возможностью быстрой фиксации убытков на каждом этапе. Вы же предлагаете заплатить все деньги где-то на этапе котлована. Как показывает практика, такие "инвестиции" далеко не всегда кончаются хорошо (в том числе и по срокам, и по стоимости квартиры). А это ведь прямая аналогия вашего plan ahead и продажи разработки по fixed cost.

M>А там и до "рефакторингов" скорее всего дело не дошло. Я так подозреваю, что они получили честный velocity на разработке и решили, что продолжать смысла нет. Это совсем не из-за подпорок. Это из-за того, что с нормальным качеством они получили объективную скорость и команда не успевала. А вот при "гонке за планом" было бы готово уже "90% модулей", но вот при интеграции и тестировании вылезла бы куча проблем. И не важно, был бы план двухнедельным (с целью его догнать!) или с неравными интервалами для разных модулей.

Все именно так и было. С одной добавкой, изначально (в самом начале проекта) планировалось, что через 3 месяца к нам присоединятся опытные разработчики, занятые на тот момент поддержкой старой версии продукта. Потому что по тому самому big upfront plan и традиционному менеджменту, допиливать критические фиксы надо было где-то еще с месяц.

По факту же получилось, что через 3 месяца к нам не только не присоединились те программисты, но еще и у нас забрали человека из команды в помощь терпящим бедствие соседям. После чего честные измерения velocity показали, что в ближайший год конкурентноспособного релиза не будет и можно на этом сворачиваться.

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

Не готов обсуждать современную молодежь. Более того, само понятие "молодежь" весьма расплывчато, кому-то и 40-летние молодежь, а кому-то и 30-летние — деды.
Достаточный опыт работы в индустрии на очень разных ролях (даже с забегом в чистую аналитику — вообще далекую от программирования и управления) дает мне возможность обоснованно утверждать, какие идеи и процессы работают. В каких условиях и почему. "Грамотно организовать процесс", это, извините, очень расплывчатое определение, под которое можно подвести что угодно.

G>а что, тимлид скрывает косяки от PMa, PM от начальства?

Для вас это новость? Открытие? Не вы ли парой сообщений назад писали про 15 лет опыта (правда, непонятно, что за опыт, коммерческий ли, фуллтайм ли, в какой индустрии, и чем вообще приходилось заниматься).

G>"задушевные беседы", "саботирует проект", "устаканивать архитектуру", "не иметь работающего продукта вообще". — ну если это ваше представление ситуации в традиционной разработки

Вы утверждаете, что этого всего нет в традиционной разработке? Если вы вправду _никогда_ с таким не встречались — могу лишь позавидовать вашей удаче.

G>недостатки:
G>1. ритмичность итераций. Следствие: архитектурные проблемы
G>2. готовый продукт после каждой итерации. Следствие: никому не нужный абсурд, занимающий дополнительное время и архитектурные проблемы
G>3. самоорганизация. Следствие: "лебедь, рак и щюка"
G>4. общее владение кодом и общая ответственность за код. Следствие: знаю обо всем помаленьку — не знаю ничего.
G>5. отсутствие распределения разработки функционала в зависимости от квалификации разработчика. Следствие: снижение качества и/или скорости разработки

Понятно.
Вы никогда не работали в скрам-команде. СкрамНо — это не Скрам. Вы даже основы не хотели осилить. В частности, архитектурные проблемы из-за ритма итераций (1) — абсурд, который вменяемый человек постеснялся бы вообще писать. Опять же, впервые слышу и том, чтобы наличие готового продукта (2) вело к архитектурным проблемам
Общее владение кодом не является атрибутом scrum и вообще agile. Вы спутали книжки. Даже не знаю, с чем. С ХР, вестимо? Равно как и отсутствие специализации внутри команды не имеет никакого отношения к скрам. Разумеется, члены команды имеют разное образование и разные знания о разных частях системы. Кто-то больше занимается БД, кто-то сетями. С чего бы вдруг им заставлять друг друга делать то, что они не умеют? Вы точно скрам с ХР не путаете?

Остается лишь вопрос самоорганизации. По вашему мнению, люди самостоятельно не способны орзанизоваться. Могу предположить лишь одно — вам катастрофически не везло с коллегами. В моем опыте как раз _внутри_ команды проблем организации не стояло. Все они возникали исключительно уровнем выше — в грызне за ступени корпоративной лестницы.

G>В скраме же команда без главного и ролей.

"Главный" есть. Это deliverables (valuable). Роли же никуда не делись, Вася как был спецом по БД, так и остался. И если сценарий требует взаимодействия с БД, скорее всего, Васю попросят эту часть реализовать. Вы однозначно перепутали скрам с чем-то другим.

G>У юниора индивидуальность это кучка амбиций и оптимистических хотелок. Он должен слушать приказы главного и советы старших, и со временем придет опыт и вырастет индивидуальность.

Мда. То вы пишете о "программисте как творческой личности", то хотите полной дедовщины. Скажите, у вас есть дети? И как, они "слушают приказы старших"?
"Вырастет индивидуальность" — это вообще смешно. Судя по всему, вы не то что руководителем проекта, а даже техническим лидером не были.

Здравствуйте, SkyDance, Вы писали:

SD>В теории, да. На практике — нет. Потому что именно итеративная разработка с жестко выделенными критериями Definition of Done является визитной карточкой SCRUM и основной его идеей.

Надеюсь это была шутка

Здравствуйте, <Аноним>, Вы писали:

А>Вот скажем я програмю . А дальше ?

Это забирает нмного времени , на безсмыссленое ченить ЧСВ. Обычно не больше чем другие формальные методики, требующие бессмысленного бреда.

Здравствуйте, DmytroL, Вы писали:

DL>Во-первых, насколько я помню, только одна из Agile-методологий, а именно — Extreme Programming, призывает не проектировать архитектуру системы заранее, но даже в XP есть понятия архитектурного прототипирования и, по сути, описывающей основные концепции дизайна метафоры системы. К тому же, XP обязательно требует наличия практики test-driven development, а это и есть методика дизайна кода, только альтернативная традиционному рисованию UML-диаграмм.

UML нарисовать намного проще и быстрее, чем писать код. TDD нечто вроде библии, слепо следуя которой потратишь кучу времени, а бизнес результат будет сомнительный. Это я о "заповеди" "пишем чтобы тест проходил, потом рефакторим". В этой "заповеди" не указаны временные метки, когда это надо делать. Когда есть утвержденные требования, то код можно написать хорошо сразу и предвидя возможные изменения или доработки заложить их в дизайн. Если потом потребуются дополнительный функционал, после завершения текущей задачи, вот тогда и только тогда доделываем дизайн и рефакторим, если надо. В рамках одной задачи писать так, чтобы сначала тест просто проходил, а потом рефакторить и доводить до ума — отсутствие опыта.

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

Здравствуйте, diez_p, Вы писали:

_>Это я о "заповеди" "пишем чтобы тест проходил, потом рефакторим". В этой "заповеди" не указаны временные метки, когда это надо делать. Когда есть утвержденные требования, то код можно написать хорошо сразу и предвидя возможные изменения или доработки заложить их в дизайн.

Ключевая фраза — "когда есть утвержденные требования", потому как методология XP, откуда и произошла "заповедь", создавалась для случая, когда требования постоянно меняются.

_> Если потом потребуются дополнительный функционал, после завершения текущей задачи, вот тогда и только тогда доделываем дизайн и рефакторим, если надо.

Авторы "заповеди" именно это и имели в виду, предостерегая от того, что называется "overengineering" (придумывание универсального кода на все случаи жизни там, где нужно решить конкретную задачу)

_> В рамках одной задачи писать так, чтобы сначала тест просто проходил, а потом рефакторить и доводить до ума — отсутствие опыта.

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

_>На счет изменчивых требований, тут есть некоторое наблюдение: при хорошей архитектуре и хорошем дизайне, большинство новых требований "стройно" ложится в архитектуру и уже существующий дизайн.

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

Здравствуйте, diez_p, Вы писали:

_>UML нарисовать намного проще и быстрее, чем писать код. TDD нечто вроде библии, слепо следуя которой потратишь кучу времени, а бизнес результат будет сомнительный. Это я о "заповеди" "пишем чтобы тест проходил, потом рефакторим". В этой "заповеди" не указаны временные метки, когда это надо делать.

Указаны. Сразу как только тест стал зеленым.

_>Когда есть утвержденные требования,

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

_>то код можно написать хорошо сразу и предвидя возможные изменения или доработки заложить их в дизайн.

Это миф. То же самое, что код можно написать сразу без ошибок.

_>Если потом потребуются дополнительный функционал, после завершения текущей задачи, вот тогда и только тогда доделываем дизайн и рефакторим, если надо. В рамках одной задачи писать так, чтобы сначала тест просто проходил, а потом рефакторить и доводить до ума — отсутствие опыта.

Причесать написанный код перед пуллом закрытого таска это отсутствие опыта?

_>На счет изменчивых требований, тут есть некоторое наблюдение: при хорошей архитектуре и хорошем дизайне, большинство новых требований "стройно" ложится в архитектуру и уже существующий дизайн.

Тот же миф. Чаще встречается архитектура которая предусматривает все, что угодно, кроме свежего требования которое нужно вчера. Между прочим архитектура совершенно не бесплатно дается, это жесткие рамки, в которые приходится втискивать код. И хорошая архитектура это не та, в которую вписываются все новые требования, а та, которая ставит меньше рамок, не давая при этом проекту превратиться в спагетти. В идеале ее вообще не заметно, но она, как тот суслик, есть.

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

Здравствуйте, Ziaw, Вы писали:


Z>Тот же миф. Чаще встречается архитектура которая предусматривает все, что угодно, кроме свежего требования которое нужно вчера. Между прочим архитектура совершенно не бесплатно дается, это жесткие рамки, в которые приходится втискивать код. И хорошая архитектура это не та, в которую вписываются все новые требования, а та, которая ставит меньше рамок, не давая при этом проекту превратиться в спагетти. В идеале ее вообще не заметно, но она, как тот суслик, есть.
Да, да, да. Конечно, конечно. А вот фиг. Хорошая архитектура позволяет легко реализовывать новые требования. И требует мало доработок для требований которые в нее не вписываются в 95% случаев. И у меня как-то так интуитивно получается что действительно, практически все места где закладывал на будущее пригодились. Хотя могло пройти пол года после разработки куска. Ни разу не видел идеальной архитектуры которую незаметно. Это наверно что-то из разряда сферических коней в вакууме. Да и вообще идеальной архитектуры не бывает, ибо требования к идеальной архитектуре противоречивы. Архитектура это компромисс, в любом случае.

А>Вот скажем я програмю . А дальше ?
Ой вей, это такая ржака
Мне повезло и в полном объеме я с этим цирком не сталкивался.

Максимум что было это срам scrum т.е. это когда на минут 10 теоретически а фактически на 0.5 час
все рассказывают чем занимались/будут. Не то что бы это было прямо очень полезно каждый день
, но немного проясняет ситуацию.

Хотя нет... Когда в офисе работал погнали как то всех на этот Agile, в смысле лектора слушать.
Как в совковые времена когда приезжал лектор и про стриптиз всем рассказывал.
Я сел в самой дльной точке зала посмотреть на этот цирк, так они потом заставили народ и за макарон, лапши и пластелина
лепить вавлиноскую башню за ограниченное время.

N>Я сел в самой дльной точке зала посмотреть на этот цирк

Т.е. вы так и не смогли преодолеть свои предубеждения? Для программиста это не лучшее качество.

Здравствуйте, Аноним931, Вы писали:

А>В вашей фирме — может быть, и 99.9%. В среднем по планете — гораздо меньше.
А>Существует множество фирм, работающих по старой доброй схеме концепция-разработка-сдача, и по соотношению дохода на сотруднико-рыло легко переплевывающих весь суперкульный ультрамодерный agile-детсад.

Ну, как бы это сказать... Доход на рыло — не показатель ни разу. Кусочек прошлой жизни: супер-пупер контора, торгуется на бирже, ежегодно загребает даже не миллионы, инвесторы счастливы до последнего миноритария. Однако внутренняя организация работ — ад. Сроки исполнения со всеми waterfall-согласованиями — ад. Попробовали аджайл — опять получился ад. Потому что проблема не в workflow.

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

Здравствуйте, goondick, Вы писали:

G>да, без чейнж-реквестов редко обходится, но это один-два максимум а не "в течение всего времени", и их легко подшить к бухгалтерии и к долгосрочному планированию. не надо драматизировать, так как это все равно лучше бардака который творится при агиле (при взгляде со стороны заказчика)

Господин, возьмите меня в свою Вселенную. Я есть много уметь. Моя полезный! Вы иметь такой хороший заказчики. Знать что хотеть.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Хороший человек по имени Peter Viscarola, который является одним из лучших специалистов по ядру Windows за пределами MS, помнится, сильно ругал Agile.

MSS>Причина: эта методология приучает людей писать код наспех, без должного внимания, приводит к медленной сходимости числа багов к нулю, и в отраслях девелопмента с высокой (по человеко-часам исправления) ценой баги может просто убить проект. Что не раз и случалось.

Т.е. во всё виноват аджайл. И когда waterfall-проект начинает вываливаться за сроки и бюджеты, там продолжают вдумчиво писать код и питаться святым духом, а затем раз — и с помощью машины времени отправляют дискету с исходниками на стол глав-инженеру на дату релиза?

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

Здравствуйте, Аноним, Вы писали:

А>Вот скажем я програмю . А дальше ?

Есть два аджыле, не ясно, какой ты имеешь ввиду.

Первый — всё, как и раньше, "я(мы) программлю(руковожу, планирую, тестирую)", только добавляются спринты, автоматические тесты, мега-митинги и прочие приседания. Ничего не меняется, добавляется только геморрой, а процесс в целом тот же ватерфол что и раньше. Это 90% контор, сорта энтерпрайза, заказной софт и прочее пиление бабла. Баззворды собираются по принципу "это скрам(аджыле)", "так правильно", "мы решили", "а что непонятно ?"

Второй — меняются принципы решения проблем, планирования, проектирования, кодинга и тестирования. Подход напоминает примерно оперативно-розыскную деятельность, а спринты и прочие баззворды выбираются в соответствии с конкретной ситуацией, и решают вполне конкретные проблемы. Это 10% контор, в основном продуктовые и хардкорно-эффективные аутсорсеры, которые решают проблемы, а не пилят бабло.

Здравствуйте, DmytroL, Вы писали:

DL>На масштабе проекта, который будет делать команда из более чем 100 человек, прописать требования так, чтобы потом их не пришлось менять, попросту невозможно [...]

Гуглим "Сетевая модель планирования".
В этоху СССР так реализовывали проекты значительно больших масштабов, при этом укладываясь в план.