Ответы пользователя по тегу Agile
  • Как реорганизовать процесс разработки и увеличить её скорость, если нету документации, куча костылей и старый код?

    Sir_Waat
    @Sir_Waat
    Business Analytics, Scrum Master
    Дабы не повторяться хочу сказать еще одну мысль, которая помогла некоторым проектам.
    Иногда кол-во "фич" и костылей зашкаливает, а технологии устаревают настолько, что единственным адекватным решением является стать "фениксом".
    Иногда стоит переписать все заново используя старые наработки и перенеся необходимый функционал в новую среду. В таком случае появляется возможность начать вести все необходимые типы документации.
    Конечно же этот способ работает только в случае подобном вашему. т.е. когда Вы обладаете достаточным объемом ресурсов (время и финансы) для найма профессионалов, способных на подобное действие. Максимально упростив текущую схему, перенеся её на новый функционал и обзаведшись хотя бы минимально необходимой документацией Вам будет легче сопровождать и модифицировать то, что Вы получите в итоге.
    Разумеется это ОЧЕНЬ сложный и рискованный шаг, но иногда сделать заново гораздо проще чем реанимировать умирающее.
    Ответ написан
    Комментировать
  • Как в Agile обходят вопрос с тем, что задача была оценена очень амбициозно?

    Sir_Waat
    @Sir_Waat
    Business Analytics, Scrum Master
    Я конечно может поздно спохватился, но Вы простите меня, таких глупостей в комментариях не читал уже давно.
    Для Вашего вопроса есть 3 основных правила (перечислю их, если кто-то еще наткнется на него в будущем):
    1) разбивка на подзадачи
    Любая задача больше 20 сторипойнтов должна разбиваться на подзадачи для контроля и нормального выполнения. Вплоть до 1. Сделаь первую часть 2. Сделать вторую часть 3. Собрать все вместе
    2) 40 часов - человеко-неделя? Пффф! Вздор!
    Если вы считаете, что возможно работать эффективно 40 часов в неделю (не отвлекаясь, простите, на туалет или попить воды), то вы глубоко ошибаетесь. Возможно причина заложена в этом. Статистика и горькой опыт говорят нам, что идеальный, повторюсь, идеальный человеко-день подразумевает 6 часов вовлеченного рабочего процесса. Так что возможно проблема как раз в неправильном понимании.
    3) Оценка задач
    Оценка задач нужна для планирования, а не для отчетности. Если вы неравильно оценили задачу, то в конце спринта Вы переоцениваете её не для того, чтобы начальник выдал Вам зарплату за каждый час работы, а для того, чтобы понять 2 вещи: 1. У Вас есть проблема с оценками задачи. 2. Вы неправильно формируете кол-во задач на спринт. Как дальше танцевать с этой информацией - выбор каждого отдельного менеджера.
    Надеюсь мой ответ был не слишком резок и еще хоть кому-то полезен.
    Всех благ! (:
    Ответ написан
    Комментировать
  • А как вы готовите грумминг для болишьх команд?

    Sir_Waat
    @Sir_Waat
    Business Analytics, Scrum Master
    Как вариант следует дать возможность заранее ознакомиться с задачами в бэклоге. Если же не все, то хотя бы определенное кол-во. Сформированный заранее план действий уменьшит время размышлений.
    Второй вариант более рискованный: следует выбрать 1-2 опытных разрабов и перед планингом позволить им выставить предварительные оценки от которых будут отталкиваться остальные. В какой-то степени это может быть навязывание временных рамок, но в то же время некоторым людям проще отталкиваться от уже имеющихся цифр.
    Ответ написан
    Комментировать