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

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

А>Вот скажем я програмю . А дальше?
Вы программите, вас это мало касается. Это касается вашего менеджера. Как он назначает задачи, как расставляет приоритеты, как корректирует оценки, как учитывает риски и т.д. и т.п.
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. Там еще много всего, в том числе спорного.