В своей статье Pete Deemer, chief product officer (India Research and Development) of Yahoo! и Gabrielle Benefield, senior director (Agile Development) of Yahoo! рассказывают о разнице между традиционной "водопадной" методологией разработки и Scrum, разновидностью agile-методологий. В конце приведены некоторые итоги применения скрама в яху — за 2 последних года 75 проектов компании и почти 700 человек были переведены на работу по данной методике.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
R>И, о чем тема?
Дак прочитай статью, не очень она большая... Так в общем думаю, людям разбирающимся, кто уже знаком более-менее со скрамом, будет не сильно интересно, но иллюстративнмы будут результаты, их смотри в предпоследнем абзаце, можно искать по значку процентов
Здравствуйте, Курилка, Вы писали:
К>Дак прочитай статью, не очень она большая... Так в общем думаю, людям разбирающимся, кто уже знаком более-менее со скрамом, будет не сильно интересно, но иллюстративнмы будут результаты, их смотри в предпоследнем абзаце, можно искать по значку процентов
Да прочитал я, правда, по диагонали, % видел.
Просто только что обнаружил, что дал ссылку не на ту статью с "Открытых систем" (читал ее с бумаги), вот оригинал: Двигатель программной революции — там Джеф Сазерленд (собственно автор Scrum) хвастается теми же цифрами, поминает как бы походя Yahoo, Google, Microsoft. Дык это... сам себя не похвалишь — никто и не вспомнит.
Здравствуйте, rsn81, Вы писали:
R>Просто только что обнаружил, что дал ссылку не на ту статью с "Открытых систем" (читал ее с бумаги), вот оригинал: Двигатель программной революции — там Джеф Сазерленд (собственно автор Scrum) хвастается теми же цифрами, поминает как бы походя Yahoo, Google, Microsoft. Дык это... сам себя не похвалишь — никто и не вспомнит.
Про автора — вопрос спорный, обычно вроде Швабера за такового считают, хотя были до них ещё всякие Штали, Такеучи и иже с ними
Здравствуйте, Курилка, Вы писали:
К>В своей статье Pete Deemer, chief product officer (India Research and Development) of Yahoo! и Gabrielle Benefield, senior director (Agile Development) of Yahoo! рассказывают о разнице между традиционной "водопадной" методологией разработки и Scrum, разновидностью agile-методологий. В конце приведены некоторые итоги применения скрама в яху — за 2 последних года 75 проектов компании и почти 700 человек были переведены на работу по данной методике.
Угу, обычное дело, все сравнивают все это с мистическим ватерфолом. Раньше я как-то это обычно воспринимал, как все, начиная трепетать при страшном слове ватерфол. Однако, сейчас ловлю себя на том, что на самом деле я не понимаю что такое ватерфол и ни разу за свою жизнь не видел его в работе. Я всегда верил книгам, которые про него, великий и ужасный пишут как про ад кромешный.
Первое. Пардон, who the fuckin guy waterfall is? Что это за процесс такой — на него есть стандарт? Или он существует только на страницах учебников в массовом воображении? Может быть, этим словом все кому не лень называют неорганизованную на местах разработку, когда документы пишут потому, что инструкция заставляет, и никто из команды не проходил никаких процессных тренингов?
Все пишут про великий и ужасный ватерфол, но на практике те же древние ГОСТы (где еще искать ватерфол, как не там? мне пришлось по работе ознакомится с профилными ГОСТами — отличные штуки оказались) регламентируют этапы разработкис критериями выходов, жестко не регламентируя активность на них. Ну прям как RUP, один в один. Все что задает ГОСТ — определяет этапы работ, которые должны быть оплачены, и по результатам которых проходит приемка работ (разумеется, без приемки оплату проводить нельзя). Там нет никакого ватерфола. Не заметно разрекламированных страшных ватерфольных свойств и у PSP/TSP, по которому я работал, и который если смотреть по книжным канонам — ну полный ватерфол должен быть.
Короче — когда пишут "по сравнению с ватерфол" я честно не понимаю с чем сравнивают. Сомневаюсь, что сами авторы ответов и статей это понимают. Скорее всего — с той фигней, которая выполняла у них роль процесса разработки до скрамов, а уж тут, извините, кто во что горазд. Но назвать как-то надо? Вот, видимо, и называют.
Второе. Экспертные оценки "лучше" "хуже" "много" "мало" "сложно" "просто"- в топку. Эти ответы ничего не стоят. Это банальный опрос населения с нечетко поставленным вопросом, который все понимают по разному, и усредненный ответ на который лишен смысла. Дать достоверный ответ на вопросы "как возросла ваша продуктивность" и прочие связанные вопросы можно только анализируя метрики, которых, я так понимаю, эти организации не вели до внедения скрама (не факт, что ведут после), и потому реально ничего сравнить не могут.
Здравствуйте, Gaperton, Вы писали:
G>Все пишут про великий и ужасный ватерфол, но на практике те же древние ГОСТы (где еще искать ватерфол, как не там? мне пришлось по работе ознакомится с профилными ГОСТами — отличные штуки оказались) регламентируют этапы разработкис критериями выходов, жестко не регламентируя активность на них. Ну прям как RUP, один в один. Все что задает ГОСТ — определяет этапы работ, которые должны быть оплачены, и по результатам которых проходит приемка работ (разумеется, без приемки оплату проводить нельзя). Там нет никакого ватерфола. Не заметно разрекламированных страшных ватерфольных свойств и у PSP/TSP, по которому я работал, и который если смотреть по книжным канонам — ну полный ватерфол должен быть.
Слушай, а нет где в публичном доступе этих самых ГОСТов?
Здравствуйте, Gaperton, Вы писали:
G>Все пишут про великий и ужасный ватерфол, но на практике те же древние ГОСТы (где еще искать ватерфол, как не там? мне пришлось по работе ознакомится с профилными ГОСТами — отличные штуки оказались) регламентируют этапы разработкис критериями выходов, жестко не регламентируя активность на них. Ну прям как RUP, один в один. Все что задает ГОСТ — определяет этапы работ, которые должны быть оплачены, и по результатам которых проходит приемка работ (разумеется, без приемки оплату проводить нельзя). Там нет никакого ватерфола. Не заметно разрекламированных страшных ватерфольных свойств и у PSP/TSP, по которому я работал, и который если смотреть по книжным канонам — ну полный ватерфол должен быть.
Угу, если вспомнить, что на западе про ГОСТы никто и не слышал...
G>Короче — когда пишут "по сравнению с ватерфол" я честно не понимаю с чем сравнивают. Сомневаюсь, что сами авторы ответов и статей это понимают. Скорее всего — с той фигней, которая выполняла у них роль процесса разработки до скрамов, а уж тут, извините, кто во что горазд. Но назвать как-то надо? Вот, видимо, и называют.
Хочется согласиться с этим... но что-то мешает.
Здравствуйте, Gaperton, Вы писали:
G>Второе. Экспертные оценки "лучше" "хуже" "много" "мало" "сложно" "просто"- в топку. Эти ответы ничего не стоят. Это банальный опрос населения с нечетко поставленным вопросом, который все понимают по разному, и усредненный ответ на который лишен смысла. Дать достоверный ответ на вопросы "как возросла ваша продуктивность" и прочие связанные вопросы можно только анализируя метрики, которых, я так понимаю, эти организации не вели до внедения скрама (не факт, что ведут после), и потому реально ничего сравнить не могут.
В дополнение можно сказать, что переход на новый процесс разработки, как правило, дает временный прирост продуктивности (почему-то возрастает мотивация инженеров). Это усложняет оценку эффективности нового процесса.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>Все пишут про великий и ужасный ватерфол, но на практике те же древние ГОСТы (где еще искать ватерфол, как не там? мне пришлось по работе ознакомится с профилными ГОСТами — отличные штуки оказались) регламентируют этапы разработкис критериями выходов, жестко не регламентируя активность на них. Ну прям как RUP, один в один. Все что задает ГОСТ — определяет этапы работ, которые должны быть оплачены, и по результатам которых проходит приемка работ (разумеется, без приемки оплату проводить нельзя). Там нет никакого ватерфола. Не заметно разрекламированных страшных ватерфольных свойств и у PSP/TSP, по которому я работал, и который если смотреть по книжным канонам — ну полный ватерфол должен быть.
К>Слушай, а нет где в публичном доступе этих самых ГОСТов?
Вроде как нет, доступ к ГОСТам вообще говоря платный. Мы недавно запросили госты по стандартам DVB (цифровое телевидение), так за это надо платить, если мне память не изменяет, 40 тыщ рублей. ГОСТ на разработку микролектроники лежит у коллеги на столе, остальные надо запрашивать в специальном отделе. То, что есть в наличии — они выдают только в печатном виде. Можно попробовать в сети поискать.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>Все пишут про великий и ужасный ватерфол, но на практике те же древние ГОСТы (где еще искать ватерфол, как не там? мне пришлось по работе ознакомится с профилными ГОСТами — отличные штуки оказались) регламентируют этапы разработкис критериями выходов, жестко не регламентируя активность на них. Ну прям как RUP, один в один. Все что задает ГОСТ — определяет этапы работ, которые должны быть оплачены, и по результатам которых проходит приемка работ (разумеется, без приемки оплату проводить нельзя). Там нет никакого ватерфола. Не заметно разрекламированных страшных ватерфольных свойств и у PSP/TSP, по которому я работал, и который если смотреть по книжным канонам — ну полный ватерфол должен быть. R>Угу, если вспомнить, что на западе про ГОСТы никто и не слышал...
ГОСТ Р ИСО 9000:2001 — это, по твоему, что? Это официальный перевод ISO 9000, про который на западе многие слышали. И таких ГОСТов много. Вообще — слышали, не слышали — это не имеет значения, на самом деле. Слабо мне верится, что наши ГОСТы писались без оглядки на западный опыт, и что наши ГОСТы сильно продвинутее западных подходов. Скорее, наоборот.
G>>Короче — когда пишут "по сравнению с ватерфол" я честно не понимаю с чем сравнивают. Сомневаюсь, что сами авторы ответов и статей это понимают. Скорее всего — с той фигней, которая выполняла у них роль процесса разработки до скрамов, а уж тут, извините, кто во что горазд. Но назвать как-то надо? Вот, видимо, и называют. R>Хочется согласиться с этим... но что-то мешает.
Ну, так в этом и вопрос. Расскажи признаки ватерфола. Мне известен из книг только один существенный — фаза четко приписана к виду активности, типа код писать во время дизайна запрещено, а если ошибка будет обнаружена в дизайне на фазе кодирования — надо откатываться на предыдущую фазу (дизайна). Вообще — это бред, никакого "откатывания" на практике не делают. Фаза, которая началась, продолжается до своего окончания. И разумеется, ошибки дизайна совершенно спокойно правят во время кодирования. По другому нельзя — к такому циклическому процессу просто невозможно выписать план. И никто откатывать двадцать пять раз фазу назад при обнаружении проблем в дизайне не будет — это очевидный бред. Может, я не те книги читал? Дайте ссылку на нормальные.
Здравствуйте, the_dip, Вы писали:
_>Здравствуйте, Gaperton, Вы писали:
G>>Второе. Экспертные оценки "лучше" "хуже" "много" "мало" "сложно" "просто"- в топку. Эти ответы ничего не стоят. Это банальный опрос населения с нечетко поставленным вопросом, который все понимают по разному, и усредненный ответ на который лишен смысла. Дать достоверный ответ на вопросы "как возросла ваша продуктивность" и прочие связанные вопросы можно только анализируя метрики, которых, я так понимаю, эти организации не вели до внедения скрама (не факт, что ведут после), и потому реально ничего сравнить не могут.
_>В дополнение можно сказать, что переход на новый процесс разработки, как правило, дает временный прирост продуктивности (почему-то возрастает мотивация инженеров). Это усложняет оценку эффективности нового процесса.
Нам консультанты, внедрявшие PSP/TSP говорили другое. Они утверждали, что в первый год внедрения новых процессов разработки после неорганизованной разработки продуктивность падает. Пока инженеры не привыкнут. Не знаю, насколько это касается скрама, но насчет PSP/TSP они правы — раньше чем через полгода точно просветление не наступает.
Мне кажется, тут основной момент не в разработчиках, а в менеджменте. Внедрение методологии играет для них роль ликбеза — их в принудительном порядке учат технологическому процессу и указывают их место в этом процессе. А менеджеры, в отличии от разработчиков, в большей степени некомпетентны, до такой степени, что зачастую могут свести на ноль или минус работу большого количества людей. С этой точки зрения — действительно неважно, какой процесс, польза по любому будет .
Здравствуйте, Gaperton, Вы писали:
G>Ну, так в этом и вопрос. Расскажи признаки ватерфола. Мне известен из книг только один существенный — фаза четко приписана к виду активности, типа код писать во время дизайна запрещено, а если ошибка будет обнаружена в дизайне на фазе кодирования — надо откатываться на предыдущую фазу (дизайна). Вообще — это бред, никакого "откатывания" на практике не делают. Фаза, которая началась, продолжается до своего окончания. И разумеется, ошибки дизайна совершенно спокойно правят во время кодирования. По другому нельзя — к такому циклическому процессу просто невозможно выписать план. И никто откатывать двадцать пять раз фазу назад при обнаружении проблем в дизайне не будет — это очевидный бред. Может, я не те книги читал? Дайте ссылку на нормальные.
Ну так, может, потому и книг нет, что бред? И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить. Хотя люди, которые искренне верят в то, что можно все продумать заранее, есть. И практикуют они итерационный процесс с каждой итерацией по пол-года, где первые два месяца идет исключительно анализ требований для итерации, вторые два месяца — дизайн, последние — кодирование и тестирование. И планы на итерацию составляют. Почему невозможно? Очень даже возможно, ведь "откатов" быть не должно, если все хорошо продумать заранее. А кто не может продумать, у того руки кривые.
G>Слабо мне верится, что наши ГОСТы писались без оглядки на западный опыт, и что наши ГОСТы сильно продвинутее западных подходов.
Тем не менее часто это именно так. Просто по той причине, что наши ГОСТы основываются на ISO и зарубежных военных стандартах (в последнее время всё больше), а на наши ГОСТы смотрит только бывшая зона влияния СССР.
D>И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить.
Не говорят. Говорят:
— После согласования требований формируем окончательный бюджет, начинаем разработку, после окончания разработки тестируем и принимаем продукт по согласованным требованиям.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Курилка, Вы писали:
К>>Слушай, а нет где в публичном доступе этих самых ГОСТов?
AL>кое-что
Это круто, но это на самом деле маленько не то — то ЕСКД (единая система конструкторской документации) и ЕСПД (программной документации).
А по процессам разработки надо немного другое — "порядок выполнения опытно-конструкторских работ". У меня есть военный ГОСТ РВ 15.203-2001 со штампом и в печатном виде. Цитирую:
Этот стандарт устанавливает:
группы ОКР
этапы ОКР
требования к выполнению ОКР
порядок выполнения и приемки этапов ОКР
функции основных участков ОКР и их взаимоотношения
Однако, цель данного стандарта состоит в том, чтобы регламентировать отношения заказчика и исполнителя по военному государственному заказу, а также упорядочить ход самих работ. Это накладывает определенный отпечаток . Там очень тяжеловесный документооборот, и рассчитано это на очень объемные проекты, например — разработка комплекса ПВО, вместе с ракетами, ПО, вычислительной машиной, и всей-превсей лабудой. Хотя, в принципе, все по делу — явно бредовых вещей в стандарте не обнаружено.
Здравствуйте, VGn, Вы писали:
G>>Слабо мне верится, что наши ГОСТы писались без оглядки на западный опыт, и что наши ГОСТы сильно продвинутее западных подходов.
VGn>Тем не менее часто это именно так. Просто по той причине, что наши ГОСТы основываются на ISO и зарубежных военных стандартах (в последнее время всё больше), а на наши ГОСТы смотрит только бывшая зона влияния СССР.
Не понял. Уточни, что именно так по твоему?
1) госты писались без оглядки на западный опыт.
2) Наши госты сильно продвинутее западных подходов.
Здравствуйте, Gaperton, Вы писали:
G>Это круто, но это на самом деле маленько не то — то ЕСКД (единая система конструкторской документации) и ЕСПД (программной документации). G>А по процессам разработки надо немного другое — "порядок выполнения опытно-конструкторских работ". У меня есть военный ГОСТ РВ 15.203-2001 со штампом и в печатном виде.
По приведенной ссылке надо смотреть надо ЕСС АСУ. В частности по стадиям -- ГОСТ 34.601-90. Гражданские фирмы, занимающиеся автоматизированными системами, обычно следуют этим стандартам.
Здравствуйте, VGn, Вы писали:
D>>И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить.
VGn>Не говорят. Говорят: VGn>- После согласования требований формируем окончательный бюджет, начинаем разработку, после окончания разработки тестируем и принимаем продукт по согласованным требованиям.
Я так понял по вашей переписке, что я убежденный последователь waterfall, и горжусь этим
А что, можно разрабатывать продукты по другому? Если это именно продукт, который будет продаваться, то тогда не дай вам бог требования от маркетинга прощелкать, и не протестировать на соответствие. У вас в случае разработки собственного продукта по собственным требованиям есть все возможности по грамотному управлению требованиями и для предварительного проектирования. Не воспользоваться этими возможностями — это разгильдяйство, а применение в том случае методик, отрицающих предварительное проектирование — оправдание разгильдяйства.
Если же это заказная разработка, и требования не ясны, то можно посмотреть, как такая проблема решается при госзаказе. А решается она очень просто — сначала открывают НИР с целью уточнения требований, результат которого — аналитика (какие эксперименты и прототипы вам надо написать, и сможете ли вы ими воспользоваться в дальнейших ОКР — неважно) или НИОКР для практической проверки реализуемости (часть результата — опытные образцы, т.е. прототипы). НИР, как вы понимаете, не подчиняется циклу waterfall, для НИР это не важно — там не надо трассировать требования и обеспечивать тестирование, как в ОКР. Есть, короче, разница между штучным опытным концепт-каром и серийной машиной.
Это проекты разных типов, они принципиально по разному планируются и контроллируются, естественно их надо разделять. К примеру, для исследований сложно прогнозировать продолжительность — нет никаких методов, поэтому надо вести работу итеративно и сделать в управлении акцент на целеполагание, заранее назначив фиксированную дату завершения. Чтобы что успели к этой дате, то и сдали. Но цель НИР — это не разработка программы или продукта. Цель — выяснить новые знания, снять неопределенность. Поэтому, мощно контроллировать качество прототипов на этапе НИР — выброшенные деньги. Так же как и писать полнофункицоналные прототипы.
