Про свн насамо деле верно, но многие программеры не пишут внятных комментов. Многие комитятся раз в неделю. Это неправильно, но кто должен решать эти вопросы? Я. Хрен там, у меня других задач погорло. ПМ? Да он в этом не разбирается, а любое преложение откладывается в долгий ящик. Может вот техдир таки введет такую практику.
По поводу отчетности. Например в РБК она используется для оценки капитализации компании для аудиторов. Без них никак. Но я совсем не настаиваю на такой системе. Она предложена лишь как некий компромис. Гораздо проще потратить 10-15 мин в конце дня, чем отвлекаться 10 раз за день на минутные вопросы. И чтоб не засерали JIRA.
В целом то что вы написали, это верно и я не спорю. И про версии и про сабтаски. Но все это должно быть не так как. Все это должно автоматически выходить из процесса а не навязываться свыше в отрыве от других практик. И я ппротив что бы этим засерали JIRA
Некоторые подходы требуют от команды производства «артефактов». Такие искусственно созданные объекты едва заметны, и, возможно, они имеют некоторые связи с реальностью. Документы анализа демонстрирует чьи-то размышления о ситуации; документация требований вносит ясность в то, что мы хотим; проекты показывают, что кто-то представил себе как это сделать; отчёты тестирования показывают, что кто-то разработал документ о том, как определить актуальную работоспособность вещей.
Просто делать
Другой распространённый подход заключается в сваливании требований на разработчиков и информировании о сроке завершения. Некоторые более «просвещённые» менеджеры могут потребовть от разработчиков оценить, когда работа будет сделана.
Как это работает для вас?
Вы, вероятно, как и мы, слышали о существовании организаций, которые могут заставить такие подходы работать. Тем не менее, даже если они выполнят свою работу, вы получите прошлогоднее, то есть, что вы искали год назад. Но, как правило, вы получите кучу бумаг, которые ни одному человеку, в том числе и пользователю, непонятны. А программа, полученная слишком поздно и с превышением бюджета, не даст вам того, что на самом деле требуется.
Вот об этом, о таких вот артифактах и идет здесь речь. Как раз говорится что «акие искусственно созданные объекты едва заметны». Далее, пряма как по мотивам темы этого топика автор предупреждает о «сваливании требований на разработчиков и информировании о сроке завершения». И называется все это «Старый путь»
То против чего я и выступаю. Безусловно это лучше чем совсем ничего, но есть другие, более эффективные пути.
начните с этого. Книга совсем не про методики быстрой разработки но вам это поможет глубже их понять. Потому что во главе угла каждой из этих методик стоит как раз человеческий фактор.
Надеюсь дотянем до корпоратива))) Но какой-то он нелюдимый, и кажется что он неуверен. Ну чувствуется неуверенность, может я и ошибаюсь. Но если не ошибаюсь. то это плохо. Потому что неуверенный человек часто подкрепляет свою неуверенность упрямостью обычно. Тогда переубедить его не удастся точно.
как убедит? Увольнением?)))
конфликт наверное не назревает так как я пока понятия не имею что он задумал. Может в комплексе это и будет выглядеть разумно, или скажем разумность всех остальных действий затмит этот небольшой косячек. Ну и мы потихоньку или тихо забьем, а в общем успехе от остальных действий техдира это как бы потеряется.
Но пока у меня ощущение что техдир нас расценивает как станки с програмным управлением. Заложил программу, и они строкают код. Заложил другую, строкают другой код. Подправил програму немного — строгают быстро.
просто неп надо впадать в крайности. Отчет должен заполняться минут 15 максимум в максимально свободной форме. Да и нужен он скорее для самоконтроля, и для самоотмазки типа «что я делал все это время? так вот посмотрите»
Из поста так сути и не уловил. Наверное и правда лучше статейку. Глаавное что понял это то, что прежде чем браться за постановку процесса, нужно его понимать, каждую мелочь, для чего все это, какие плюсы и минусы, чем грозит, какую пользу дает. Нужно не только знать что делать, но и понимать для чего это все нужно, на какие такие точки мы надавливаем той или иной практикой, какие рычажки дергаем. Не поверхностное зазубренное, а глубокое понимание методики необходимо.
Честно говоря, я так же прочел много книг, много применял сам, когда была возможность. много убеждал применять ПМ-ов, и смотрел на результат. Каждую практику обдумал и переварил не раз. Мне это интересно. Но читая многих здесь отписавшихся, прихожу у выводу что многие слишком поверхностно понимают этот вопрос. Видят лишь общие аспекты, лежащие на поверхности. Но эффективность Agile-методик как раз и происходит от того что они, немотря на кажущуюся простоту, очень тонкие и многогранные. Их применение дергает понемножку за множество ниточек, незамтно превращая все в живой механизм. Тут и техпроцессы, тут и психология, тут и невидимые вроде бы рамки, за которые просто не получится выйти. И главное, конечно это человеческий фактор. Часто как раз вопрос человеческого фактора упускается из виду, как в приведенном здесь случае. Что кстати меня сразу и насторожило.
если у вас такой стиль разработки и вы укладываетесь в сроки, то так и пишите «болела голова ничего не делал». Если в итоге вы удовлетворяете всех, то никто и слова не скажет. В отчетах главное честность.
По поводу отчетности. Например в РБК она используется для оценки капитализации компании для аудиторов. Без них никак. Но я совсем не настаиваю на такой системе. Она предложена лишь как некий компромис. Гораздо проще потратить 10-15 мин в конце дня, чем отвлекаться 10 раз за день на минутные вопросы. И чтоб не засерали JIRA.
В целом то что вы написали, это верно и я не спорю. И про версии и про сабтаски. Но все это должно быть не так как. Все это должно автоматически выходить из процесса а не навязываться свыше в отрыве от других практик. И я ппротив что бы этим засерали JIRA
Цитата
Старый путь
Тяжёлые артефакты
Некоторые подходы требуют от команды производства «артефактов». Такие искусственно созданные объекты едва заметны, и, возможно, они имеют некоторые связи с реальностью. Документы анализа демонстрирует чьи-то размышления о ситуации; документация требований вносит ясность в то, что мы хотим; проекты показывают, что кто-то представил себе как это сделать; отчёты тестирования показывают, что кто-то разработал документ о том, как определить актуальную работоспособность вещей.
Просто делать
Другой распространённый подход заключается в сваливании требований на разработчиков и информировании о сроке завершения. Некоторые более «просвещённые» менеджеры могут потребовть от разработчиков оценить, когда работа будет сделана.
Как это работает для вас?
Вы, вероятно, как и мы, слышали о существовании организаций, которые могут заставить такие подходы работать. Тем не менее, даже если они выполнят свою работу, вы получите прошлогоднее, то есть, что вы искали год назад. Но, как правило, вы получите кучу бумаг, которые ни одному человеку, в том числе и пользователю, непонятны. А программа, полученная слишком поздно и с превышением бюджета, не даст вам того, что на самом деле требуется.
Вот об этом, о таких вот артифактах и идет здесь речь. Как раз говорится что «акие искусственно созданные объекты едва заметны». Далее, пряма как по мотивам темы этого топика автор предупреждает о «сваливании требований на разработчиков и информировании о сроке завершения». И называется все это «Старый путь»
То против чего я и выступаю. Безусловно это лучше чем совсем ничего, но есть другие, более эффективные пути.
конфликт наверное не назревает так как я пока понятия не имею что он задумал. Может в комплексе это и будет выглядеть разумно, или скажем разумность всех остальных действий затмит этот небольшой косячек. Ну и мы потихоньку или тихо забьем, а в общем успехе от остальных действий техдира это как бы потеряется.
Но пока у меня ощущение что техдир нас расценивает как станки с програмным управлением. Заложил программу, и они строкают код. Заложил другую, строкают другой код. Подправил програму немного — строгают быстро.
Честно говоря, я так же прочел много книг, много применял сам, когда была возможность. много убеждал применять ПМ-ов, и смотрел на результат. Каждую практику обдумал и переварил не раз. Мне это интересно. Но читая многих здесь отписавшихся, прихожу у выводу что многие слишком поверхностно понимают этот вопрос. Видят лишь общие аспекты, лежащие на поверхности. Но эффективность Agile-методик как раз и происходит от того что они, немотря на кажущуюся простоту, очень тонкие и многогранные. Их применение дергает понемножку за множество ниточек, незамтно превращая все в живой механизм. Тут и техпроцессы, тут и психология, тут и невидимые вроде бы рамки, за которые просто не получится выйти. И главное, конечно это человеческий фактор. Часто как раз вопрос человеческого фактора упускается из виду, как в приведенном здесь случае. Что кстати меня сразу и насторожило.