aissp писал(а):вообзе то sprint ето основополагаюший кирпич scum/ Пользовал scrum в двух версиях тяжелой (с покерными митингами) и легкой когда сам себе estimation выставляешь. Также работал в довольно больших проектах с "waterfall". Agile не нравится, начиная от митингов 15 минутных и красивых графиков по майлу в обегченном варианте, так и мучительным планированием спринта с обязательным достижением консенсуса. Вот как разработчику не нравится он мне мешает работать, отвлекая на не нужные пляски с бубнами. Продолжаю считать что Jira или Mantiss вполне достаточно для разработки проекта в гигабайт соурс кода
Любая методология разработки программного обеспечения ставит своей задачей организовать работу программистов и тестировщиков (людей непосредственно создающих продукт) таким образом, чтобы получить на выходе продукт удовлетворящий требованиям Заказчика и обладающим необходимым качеством. Если бы все программисты и тестировщики сами ЗНАЛИ, что им нужно делать, то им не нужны были никакие менеджеры и никакие танцы с бубнами. Если же конечные исполнители НЕ ЗНАЮТ, что нужно делать, то велик риск того, что они не сделают то, что нужно заказчику, или, что еще хуже, сделают что-то такое, что НЕ нужно заказчику (пустив соответствующие ресурсы коту под хвост).
Один из возможных подходов (реализованный в вотерфоле) - тщательно прописать все действия программистов и тестировщиков. Однако, данный подход связан с оверхедом вызванным необходимостью разработки значительного обьема проектной и тестовой документации, а также с контролем за выполнением процесса. Кроме того, данный процесс весьма неповоротлив, даже в условиях когда нет недостатка в ресурсах.
Альтернативный подход (обычно связываемый с аджайл) основан на том, что людям нужно дать только самый необходимый минимум информации, и они сами сделают дальше все что нужно. Этот подход позволяет существенно сьэкономить на оверхеде - в предельном случае из документации присутствуют только пользовательские сценарии, комментарии в коде продукта и автотестах, а также пользовательская документация. Весь процесс проходит в виде устного общения между членами команды (плюс записей в ДТС) и его практически невозможно проконтролировать - в том смысле, как это делается в вотерфоле. Ежу понятно, что в подобных условиях, когда ничего другого нет, "танцы с бубнами" приобретают значительную роль. На это может наложиться еще и нехватка или противоречивость пользовательских требований, а также ситуации, когда у конкурента естимейт на 10% ниже, или когда пользователь скажет, что да, вы, ребята, сделали ровно то что я просил, но это совсем не то, что я хотел:)
Конечно, конечных исполнителей "танцы с бубнами" напрягают. Им проще делать то, что они хорошо знают, или то, что считают правильным (даже если это не то, что в конечном счете нужно заказчику). Это также как если в автосервис приедет машина с горящим Чек энджин, и ее владельцу предложат с ходу поменять катализатор.
