Посмотрим правде в глаза: россиянину сложно планировать.
Люди в России сильны в импровизации и умении собраться вместе в критический момент, давая потрясающие результаты.
Но жизнь показывает, что с такой идеологией команде программистов далеко не уйти.
Героические усилия в одно время не могут компенсировать безразличие в другое.
Что общего между зомби-апокалипсисом и разработкой программного обеспечения? Простые правила помогут вам выжить и в том, и в другом случае.
Этап планирования предполагает осознанную и целенаправленную деятельность коллектива на пути к достижению результата.
Определение задач, разбивка их на этапы и прогнозирование сроков — необходимый шаг на пути к реализации ваших планов.
Особенно, если речь идет о гибкой методологии Agile, которую мы считаем лучшей.
Команды разработчиков допускают эти ошибки при планировании создания программного обеспечения.
1. Планировать сроки должны программисты, а не менеджеры
Распространенной ошибкой является то, что руководитель проекта, неправильно понимая объем и специфику поставленных задач, устанавливает сроки реализации проекта не в соответствии с опытом, возможностями и компетенциями команды, а исходя из собственных идей, желаний или Запросы.Программистам таких групп не позавидуешь.
Расхождение плановых и фактических сроков составляет 40-80%.
Атмосфера в коллективе гнетущая и не способствует работе.
Проблемы следуют одна за другой, и винят в этом непосредственных разработчиков.
2. Необходимо заранее определить примерные сроки завершения всего проекта и реальные сроки решения проблемы.
Ни при каких обстоятельствах процессы нельзя оставлять на волю случая.
Игнорирование процедуры планирования приводит к расхлябанности, низкой мотивации разработчиков в периоды, предшествующие дедлайну, и непониманию командой, что делать, куда двигаться и чего нужно добиться в итоге.
В объединениях, где примерные сроки сдачи проектов не определены, целесообразно задуматься о том, что такой хаос ни к чему хорошему не приведет.
3. Разбить проект на небольшие этапы с четкими целями и обязательным обсуждением результатов
Применение принципа необходимо для противодействия закону Паркинсона, который определяет, что общий объем работы всегда будет увеличиваться, чтобы заполнить все время, отведенное на работу.Следуя этому совету, вы сможете избежать необходимости усердно работать непосредственно перед сдачей проекта.
Разбивка процесса достижения глобальной цели на контрольные периоды с необходимостью выполнения конкретных задач в течение недели-двух позволит максимально использовать рабочий потенциал команды.
При таком подходе сохраняется высокий уровень мотивации и эффективности разработчиков на протяжении всего периода создания ПО и увеличивается вероятность достижения желаемых целей.
4. Члены команды должны максимально тесно взаимодействовать друг с другом.
В первую очередь повышается сплоченность коллектива и стимулируется взаимовыручка.
При недостаточном общении между членами объединения отсутствует «командный дух», обеспечивающий слаженную работу.
Совместная производственная деятельность удовлетворяет социальные потребности человека в ощущении значимости выполняемого труда.
Соблюдение принципа позволяет безболезненно заменить любого члена команды, ведь участники знают, кто, что и как делает.
5. Запланируйте резерв времени на покрытие форс-мажорных обстоятельств, новых требований клиентов, отпусков и праздников, на интеграцию и тестирование.
На начальном этапе планирования невозможно предусмотреть все ситуации.
Поэтому необходимо оставлять время в запасе, чтобы команде не приходилось торопиться и, как следствие, совершать ошибки.
Не следует игнорировать необходимость отладки и доведения программного обеспечения до уровня стабильной работы и приемлемого количества ошибок.
Выпускать сырой продукт из-за жёсткой экономии времени нецелесообразно.
Методология Agile предполагает изменчивость внешних условий и необходимость быстрой и безболезненной адаптации к ним.
6. Нельзя торопиться, нарушать план и сокращать время разработки ПО
Распространенная ошибка менеджеров, которые думают, что программисты могут уложиться в любые сроки.Во-первых, команда демотивируется, саботирует рабочий процесс или пишет заявления по собственному желанию.
Во-вторых, резкое ускорение трудовых операций истощает ресурсы организма и психики человека, приводя к профессиональному выгоранию.
В-третьих, чрезмерный темп приводит к увеличению количества ошибок в коде.
Отладка и исправление в будущем потребуют гораздо больше времени, чем можно сэкономить таким образом.
7. Планирование документирования с помощью подходящего диспетчера задач.
Выбор конкретной программы – дело вкуса.
Планы должны быть записаны.
Наглядность необходима как для разработчиков, так и для клиентов, сохраняя при этом возможность внесения изменений.
Это позволяет улучшить взаимопонимание между командой разработчиков, руководством и клиентом.
Сокращается количество споров по поводу толкования рабочих действий.
Ясность формулировок плана поможет избежать двусмысленности.
8. Расставьте приоритеты в задачах и сосредоточьтесь на самом важном
Постарайтесь сначала реализовать самый важный функционал.Имейте в виду, что некоторыми функциями придется пожертвовать в процессе разработки, а также реализации некоторых идей.
А расстановка приоритетов возможна только посредством общения и обмена мнениями.
Что вы думаете о планировании разработки программного обеспечения? Оставляйте свои комментарии к статье.
Мы хотели бы услышать ваше мнение.
О технологиях разработки: Еще раз о семи основных методологиях разработки .
10 главных ошибок в системах масштабирования .
8 принципов планирования развития, которые упрощают жизнь .
5 основных рисков при разработке программного обеспечения на заказ .
Теги: #edisonsoftware #edisonsoftware #edisonsoftware #edison #разработка #программирование #планирование #разработка веб-сайтов #программирование
-
Легкое Управление Запасами И Прочим
19 Oct, 24 -
Цуга
19 Oct, 24 -
Потребитель Должен Продавать За Вас
19 Oct, 24
