8 принципов планирования разработки, упрощающих жизнь

    Скажем прямо, русскому человеку планировать тяжело. Люди в России сильны импровизацией и умением собираться в критический момент, выдавая поразительные результаты. Но жизнь показывает, что команда программистов на подобной идеологии далеко не уедет. Героические усилия в одно время не смогут компенсировать пофигизм в другое.


    Что общего у зомби-апокалипсиса и разработки ПО? Простые правила помогают пережить и то, и другое

    Этап планирования предполагает осознанную и целенаправленную деятельность команды на пути к достижению результата. Определить задачи, разбить на вехи, предвидеть сроки – необходимый шаг на пути воплощения задуманного. Особенно, если дело касается гибкой методологии Agile, которую считаем наилучшей.

    Команды разработчиков допускают такие ошибки при планировании создания ПО.

    1. Планировать сроки должны программисты, а не менеджеры


    Частая ошибка, когда руководитель проекта, не понимающий должным образом объем и специфику задач, устанавливает сроки проекта не в соответствии с опытом, возможностями и компетенциями команды, а опираясь на собственные представления, желания или запросы клиента. Программистам в подобных группах не позавидуешь. Расхождения запланированных и реальных сроков составляет 40-80%. Атмосфера в коллективе создается гнетущая и отбивающая желание работать. Проблемы следуют одна за другой, а виноватыми выставляются непосредственные разработчики.

    2. Необходимо заранее определять примерные сроки сдачи всего проекта и реальное время решения задачи


    Отпускать процессы на самотек ни в коем случае нельзя. Игнорирование процедуры планирования приводит к расхлябанности, низкой мотивации разработчиков в предшествующие дедлайну периоды, к непониманию командой, что делать, куда двигаться и что нужно получить в итоге. В объединениях, где примерные сроки сдачи проекта не определяются, желательно задуматься о том, что подобный хаос до добра не доведет.

    3. Проект разбивайте на мелкие этапы с четкими целями и обязательным обсуждением результатов


    Применение принципа необходимо для противодействия закону Паркинсона, определяющему, что общий объём работы всегда будет увеличиваться, чтобы заполнить всё выделенное на работу время. Следуя совету, можно избежать желания усердно трудиться лишь незадолго до срока сдачи проекта. Разбивка процесса достижения глобальной цели на контрольные периоды с необходимостью выполнения конкретных задач в течение недели – двух позволит использовать рабочий потенциал команды по максимуму. При указанном подходе поддерживается высокий уровень мотивации и работоспособности разработчиков на протяжении всего периода создания ПО и увеличивается вероятность достижения желаемых целей.

    4. Члены команды должны максимально плотно взаимодействовать друг с другом


    Прежде всего повышается сплоченность коллектива и стимулируется оказание взаимопомощи. При недостаточном общении между членами объединения отсутствует «командный дух», обеспечивающий слаженную работу. Совместная продуктивная деятельность удовлетворяет социальные потребности человека в ощущении значимости выполняемого труда. Соблюдение принципа позволяет безболезненно заменить любого члена команды, потому что участники в курсе кто, что и как делает.

    5. Включайте резерв времени для покрытия форс-мажора, новых требований заказчика, отпусков и праздников, на интеграцию и тестирование


    На первоначальном этапе планирования нельзя предусмотреть все ситуации. Поэтому нужно зарезервировать время про запас, чтобы команде не пришлось торопиться и, как следствие, совершать ошибки. Не стоит игнорировать необходимость отладки и доведения ПО до уровня стабильной работы и приемлемого количества багов. Выпуск сырого продукта из-за жесткой экономии времени не разумен. Методология Agile предполагает изменчивость внешних условий и необходимость быстрой и безболезненной адаптации к ним.

    6. Нельзя торопиться, нарушать план и уменьшать время разработки ПО


    Частая ошибка менеджеров, думающих, что программисты смогут потянуть любые сроки. Во-первых, команда демотивируется, саботирует процесс труда или пишет заявления по собственному желанию. Во-вторых, резкое ускорение рабочих операций истощает ресурсы организма и психики человека, ведет к профессиональному выгоранию. В-третьих, завышенный темп приводит к увеличению количества ошибок в коде. На отладку и исправление в будущем потребуется значительно больше времени, чем получится сэкономить подобным образом.

    7. Документируйте планирование с помощью подходящего таск-менеджера


    Выбор конкретной программы является вопрос вкуса. Планы следует фиксировать. Требуется наглядность как для разработчиков, так и для клиентов, сохраняя возможность для внесения изменений. Это позволяет улучшить взаимопонимание команды разработчиков, менеджмента и клиента. Снижается количество споров относительно трактовки рабочих действий. Четкость формулировки плана поможет избежать двоякого толкования.

    8. Расставляйте приоритеты задачам и концентрируйтесь на главном


    Старайтесь в первую очередь реализовывать наиболее важный функционал. Имейте ввиду, что какими-то фичами в процессе разработки придется пожертвовать, равно как и реализацией части идей. А расставить приоритеты возможно исключительно через общение и обмен мнениями.

    А что вы думаете по поводу планирования в разработке ПО? Оставляйте свои комментарии к статье. Мы будем рады услышать ваше мнение.



    О технологиях разработки:
    Ещё раз про семь основных методологий разработки.
    10 главных ошибок масштабирования систем.
    8 принципов планирования разработки, упрощающих жизнь.
    5 главных рисков при заказной разработке ПО.
    • +6
    • 26,9k
    • 8
    Edison 505,87
    Изобретаем успех: софт и стартапы
    Поделиться публикацией
    Комментарии 8
    • +13
      Ну сколько можно одно и тоже писать?
      • +19
        0. Не прикрывайте отсутствие аналитики гибкими методологиями разработки
        • 0
          Люто плюсую!
          • 0
            <sarcasm>
            

            Аналитики в проекте? Да зачем они вообще нужны? Код не пишут, технологий глубоко не знают, только бюджет увеличивают почем зря.
             </sarcasm>
            
            • 0
              Хороший аналитик экономит время разработчика этак раза в три. :-) При этом попутно снижая общий фоновый уровень негатива по поводу сроков. Вопрос, как определить, хороший перед тобой аналитик или не очень...
          • +5
            «Документируйте планирование с помощью подходящей программы багтреккинга»
            Пожалуйста, замените багтрекинг на тасктрекинг. Вы, вероятно, не видите разницы, но вообще баг не может быть спланирован. Могут быть спланированы задачи для устранения этого бага, и их связь с багом — многие ко многим.
            • 0
              1. Планировать сроки должны программисты, а не менеджеры

              Планировать сроки должны программисты, совместно с QA. Зачастую однострочное изменение тянет за собой пару дней на изменение тестов, не говоря уже об их прогоне.
              • 0
                > 4. Члены команды должны максимально плотно взаимодействовать друг с другом
                На практике это тяжело сделать. Если команда маленькая и проектов больше чем людей, то каждому суждено вариться в своем хозяйстве и на вникание в чужое тупо не будет времени. Если команда побольше, то уже будет разделение по обязанностям и все равно проектировщик базы вряд ли будет вникать в нюансы фронтэнда. Не было опыта работы в совсем больших коллективах, наверное, там это применимо.

                От себя добавлю любимый принцип «Сокращать асапы». Всякий раз когда мы на практике пытаемся применить методологии разработки вместо банального выделения приоритетных задач в трекере, обязательно возникают задачи плана «баг в проекте нужно закрыть не позднее вечера» или «клиент заплатил нам за эту функциональность, запуск уже завтра» и вся методология ломается. Асапы — это, конечно, неизбежное зло, но с точки зрения менеджера/аналитика нужно понимать последствия (говнокод, в продакшн без тестирования — как в Марсианине ракету запускали, куча нервов) и выставлять задачу как критическую только в критическом случае.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое